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/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 - 1132 files changed, 131862 deletions(-) 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 (limited to 'static/netbsd') 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