aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--.cirrus.yml2
-rw-r--r--documentation/Makefile4
-rw-r--r--documentation/config/_default/config.toml3
-rw-r--r--documentation/config/_default/languages.id.toml4
-rw-r--r--documentation/config/offline/config.toml13
-rw-r--r--documentation/content/de/books/handbook/advanced-networking/_index.adoc2
-rw-r--r--documentation/content/de/books/handbook/network-servers/_index.adoc6
-rw-r--r--documentation/content/el/books/handbook/mirrors/_index.adoc9
-rw-r--r--documentation/content/en/articles/committers-guide/_index.adoc137
-rw-r--r--documentation/content/en/articles/contributing/_index.adoc21
-rw-r--r--documentation/content/en/articles/contributors/_index.adoc5
-rw-r--r--documentation/content/en/articles/freebsd-releng/_index.adoc5
-rw-r--r--documentation/content/en/articles/freebsd-src-lsp/_index.adoc2
-rw-r--r--documentation/content/en/articles/freebsd-update-server/_index.adoc8
-rw-r--r--documentation/content/en/articles/hubs/_index.adoc23
-rw-r--r--documentation/content/en/articles/ldap-auth/_index.adoc2
-rw-r--r--documentation/content/en/articles/pam/_index.adoc2
-rw-r--r--documentation/content/en/articles/pgpkeys/_index.adoc441
-rw-r--r--documentation/content/en/articles/problem-reports/_index.adoc6
-rw-r--r--documentation/content/en/articles/vm-design/_index.adoc2
-rw-r--r--documentation/content/en/books/arch-handbook/_index.adoc2
-rw-r--r--documentation/content/en/books/arch-handbook/book.adoc2
-rw-r--r--documentation/content/en/books/arch-handbook/boot/_index.adoc1056
-rw-r--r--documentation/content/en/books/developers-handbook/_index.adoc2
-rw-r--r--documentation/content/en/books/developers-handbook/book.adoc2
-rw-r--r--documentation/content/en/books/developers-handbook/tools/_index.adoc2
-rw-r--r--documentation/content/en/books/faq/_index.adoc41
-rw-r--r--documentation/content/en/books/fdp-primer/doc-build/_index.adoc2
-rw-r--r--documentation/content/en/books/fdp-primer/editor-config/_index.adoc137
-rw-r--r--documentation/content/en/books/fdp-primer/overview/_index.adoc222
-rw-r--r--documentation/content/en/books/fdp-primer/po-translations/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/_index.adoc17
-rw-r--r--documentation/content/en/books/handbook/advanced-networking/_index.adoc60
-rw-r--r--documentation/content/en/books/handbook/bibliography/_index.adoc5
-rw-r--r--documentation/content/en/books/handbook/book.adoc18
-rw-r--r--documentation/content/en/books/handbook/config/_index.adoc20
-rw-r--r--documentation/content/en/books/handbook/cutting-edge/_index.adoc24
-rw-r--r--documentation/content/en/books/handbook/disks/_index.adoc20
-rw-r--r--documentation/content/en/books/handbook/eresources/_index.adoc167
-rw-r--r--documentation/content/en/books/handbook/firewalls/_index.adoc35
-rw-r--r--documentation/content/en/books/handbook/geom/_index.adoc8
-rw-r--r--documentation/content/en/books/handbook/introduction.adoc12
-rw-r--r--documentation/content/en/books/handbook/introduction/_index.adoc115
-rw-r--r--documentation/content/en/books/handbook/jails/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/linuxemu/_index.adoc10
-rw-r--r--documentation/content/en/books/handbook/mac/_index.adoc10
-rw-r--r--documentation/content/en/books/handbook/mail/_index.adoc10
-rw-r--r--documentation/content/en/books/handbook/mirrors/_index.adoc885
-rw-r--r--documentation/content/en/books/handbook/multimedia/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/network-servers/_index.adoc47
-rw-r--r--documentation/content/en/books/handbook/ports/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/preface/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/printing/_index.adoc14
-rw-r--r--documentation/content/en/books/handbook/security/_index.adoc97
-rw-r--r--documentation/content/en/books/handbook/serialcomms/_index.adoc2
-rw-r--r--documentation/content/en/books/handbook/usb-device-mode/_index.adoc4
-rw-r--r--documentation/content/en/books/handbook/wine/_index.adoc38
-rw-r--r--documentation/content/en/books/handbook/x11/_index.adoc652
-rw-r--r--documentation/content/en/books/handbook/zfs/_index.adoc7
-rw-r--r--documentation/content/en/books/porters-handbook/keeping-up/_index.adoc20
-rw-r--r--documentation/content/en/books/porters-handbook/makefiles/_index.adoc23
-rw-r--r--documentation/content/en/books/porters-handbook/order/_index.adoc12
-rw-r--r--documentation/content/en/books/porters-handbook/plist/_index.adoc12
-rw-r--r--documentation/content/en/books/porters-handbook/porting-dads/_index.adoc4
-rw-r--r--documentation/content/en/books/porters-handbook/special/_index.adoc6
-rw-r--r--documentation/content/en/books/porters-handbook/upgrading/_index.adoc10
-rw-r--r--documentation/content/en/books/porters-handbook/uses/_index.adoc212
-rw-r--r--documentation/content/en/books/porters-handbook/versions/_index.adoc127
-rw-r--r--documentation/content/fr/books/handbook/linuxemu/_index.adoc186
-rw-r--r--documentation/content/hu/books/handbook/mirrors/_index.adoc8
-rw-r--r--documentation/content/id/articles/_index.adoc8
-rw-r--r--documentation/content/id/articles/_index.po30
-rw-r--r--documentation/content/id/articles/mailing-list-faq/_index.adoc176
-rw-r--r--documentation/content/id/articles/mailing-list-faq/_index.po772
-rw-r--r--documentation/content/ja/books/handbook/_index.adoc21
-rw-r--r--documentation/content/ja/books/handbook/basics/_index.adoc151
-rw-r--r--documentation/content/ja/books/handbook/book.adoc20
-rw-r--r--documentation/content/ja/books/handbook/bsdinstall/_index.adoc32
-rw-r--r--documentation/content/ja/books/handbook/cutting-edge/_index.adoc26
-rw-r--r--documentation/content/ja/books/handbook/eresources/_index.adoc32
-rw-r--r--documentation/content/ja/books/handbook/introduction.adoc12
-rw-r--r--documentation/content/ja/books/handbook/introduction/_index.adoc56
-rw-r--r--documentation/content/ja/books/handbook/mirrors/_index.adoc773
-rw-r--r--documentation/content/ja/books/handbook/ports/_index.adoc43
-rw-r--r--documentation/content/ja/books/handbook/preface/_index.adoc55
-rw-r--r--documentation/content/ja/books/handbook/x11/_index.adoc28
-rw-r--r--documentation/content/mn/books/handbook/_index.adoc1
-rw-r--r--documentation/content/mn/books/handbook/book.adoc4
-rw-r--r--documentation/content/mn/books/handbook/bsdinstall/_index.adoc2
-rw-r--r--documentation/content/mn/books/handbook/mirrors/_index.adoc9
-rw-r--r--documentation/content/nl/books/handbook/mirrors/_index.adoc9
-rw-r--r--documentation/content/pl/books/handbook/advanced-networking/_index.adoc2
-rw-r--r--documentation/content/pl/books/handbook/network-servers/_index.adoc6
-rw-r--r--documentation/content/pt-br/articles/_index.adoc2
-rw-r--r--documentation/content/pt-br/articles/ldap-auth/_index.adoc66
-rw-r--r--documentation/content/pt-br/articles/ldap-auth/_index.po1906
-rw-r--r--documentation/content/pt-br/articles/mailing-list-faq/_index.adoc53
-rw-r--r--documentation/content/pt-br/articles/mailing-list-faq/_index.po773
-rw-r--r--documentation/content/pt-br/articles/problem-reports/_index.adoc74
-rw-r--r--documentation/content/pt-br/articles/problem-reports/_index.po1437
-rw-r--r--documentation/content/pt-br/articles/releng/_index.adoc4
-rw-r--r--documentation/content/pt-br/books/_index.adoc2
-rw-r--r--documentation/content/pt-br/books/fdp-primer/_index.adoc7
-rw-r--r--documentation/content/pt-br/books/fdp-primer/_index.po27
-rw-r--r--documentation/content/pt-br/books/fdp-primer/asciidoctor-primer/_index.adoc41
-rw-r--r--documentation/content/pt-br/books/fdp-primer/asciidoctor-primer/_index.po260
-rw-r--r--documentation/content/pt-br/books/fdp-primer/book.po33
-rw-r--r--documentation/content/pt-br/books/fdp-primer/doc-build/_index.adoc420
-rw-r--r--documentation/content/pt-br/books/fdp-primer/doc-build/_index.po1585
-rw-r--r--documentation/content/pt-br/books/fdp-primer/editor-config/_index.adoc4
-rw-r--r--documentation/content/pt-br/books/fdp-primer/editor-config/_index.po125
-rw-r--r--documentation/content/pt-br/books/fdp-primer/examples/_index.adoc31
-rw-r--r--documentation/content/pt-br/books/fdp-primer/examples/_index.po126
-rw-r--r--documentation/content/pt-br/books/fdp-primer/manual-pages/_index.adoc96
-rw-r--r--documentation/content/pt-br/books/fdp-primer/manual-pages/_index.po1336
-rw-r--r--documentation/content/pt-br/books/fdp-primer/overview/_index.adoc6
-rw-r--r--documentation/content/pt-br/books/fdp-primer/overview/_index.po107
-rw-r--r--documentation/content/pt-br/books/fdp-primer/po-translations/_index.adoc16
-rw-r--r--documentation/content/pt-br/books/fdp-primer/po-translations/_index.po1006
-rw-r--r--documentation/content/pt-br/books/fdp-primer/preface/_index.adoc18
-rw-r--r--documentation/content/pt-br/books/fdp-primer/preface/_index.po354
-rw-r--r--documentation/content/pt-br/books/fdp-primer/rosetta/_index.adoc78
-rw-r--r--documentation/content/pt-br/books/fdp-primer/rosetta/_index.po758
-rw-r--r--documentation/content/pt-br/books/fdp-primer/see-also/_index.adoc12
-rw-r--r--documentation/content/pt-br/books/fdp-primer/see-also/_index.po66
-rw-r--r--documentation/content/pt-br/books/fdp-primer/structure/_index.adoc93
-rw-r--r--documentation/content/pt-br/books/fdp-primer/structure/_index.po864
-rw-r--r--documentation/content/pt-br/books/fdp-primer/tools/_index.adoc7
-rw-r--r--documentation/content/pt-br/books/fdp-primer/tools/_index.po49
-rw-r--r--documentation/content/pt-br/books/fdp-primer/translations/_index.adoc6
-rw-r--r--documentation/content/pt-br/books/fdp-primer/translations/_index.po202
-rw-r--r--documentation/content/pt-br/books/fdp-primer/working-copy/_index.adoc4
-rw-r--r--documentation/content/pt-br/books/fdp-primer/working-copy/_index.po85
-rw-r--r--documentation/content/pt-br/books/fdp-primer/writing-style/_index.adoc4
-rw-r--r--documentation/content/pt-br/books/fdp-primer/writing-style/_index.po491
-rw-r--r--documentation/content/pt-br/books/handbook/advanced-networking/_index.adoc2
-rw-r--r--documentation/content/pt-br/books/handbook/network-servers/_index.adoc6
-rw-r--r--documentation/content/pt-br/books/porters-handbook/order/_index.adoc12
-rw-r--r--documentation/content/zh-cn/books/handbook/mirrors/_index.adoc9
-rw-r--r--documentation/content/zh-tw/books/handbook/advanced-networking/_index.adoc2
-rw-r--r--documentation/content/zh-tw/books/handbook/network-servers/_index.adoc6
-rw-r--r--documentation/content/zh-tw/books/porters-handbook/order/_index.adoc12
-rw-r--r--documentation/static/pgpkeys/aaron.key43
-rw-r--r--documentation/static/pgpkeys/adrian.key44
-rw-r--r--documentation/static/pgpkeys/adridg.key159
-rw-r--r--documentation/static/pgpkeys/alonso.key44
-rw-r--r--documentation/static/pgpkeys/amdmi3.key59
-rw-r--r--documentation/static/pgpkeys/andrew.key94
-rw-r--r--documentation/static/pgpkeys/anish.key44
-rw-r--r--documentation/static/pgpkeys/arichardson.key46
-rw-r--r--documentation/static/pgpkeys/arrowd.key51
-rw-r--r--documentation/static/pgpkeys/arun.key44
-rw-r--r--documentation/static/pgpkeys/arundel.key65
-rw-r--r--documentation/static/pgpkeys/arybchik.key70
-rw-r--r--documentation/static/pgpkeys/asiciliano.key45
-rw-r--r--documentation/static/pgpkeys/avos.key44
-rw-r--r--documentation/static/pgpkeys/badger.key53
-rw-r--r--documentation/static/pgpkeys/bf.key66
-rw-r--r--documentation/static/pgpkeys/bhaga.key65
-rw-r--r--documentation/static/pgpkeys/brd.key74
-rw-r--r--documentation/static/pgpkeys/brueffer.key574
-rw-r--r--documentation/static/pgpkeys/bushman.key47
-rw-r--r--documentation/static/pgpkeys/bwidawsk.key236
-rw-r--r--documentation/static/pgpkeys/chuck.key49
-rw-r--r--documentation/static/pgpkeys/clive.key111
-rw-r--r--documentation/static/pgpkeys/dab.key45
-rw-r--r--documentation/static/pgpkeys/danger.key107
-rw-r--r--documentation/static/pgpkeys/danilo.key108
-rw-r--r--documentation/static/pgpkeys/davidxu.key53
-rw-r--r--documentation/static/pgpkeys/dbaio.key279
-rw-r--r--documentation/static/pgpkeys/dbn.key121
-rw-r--r--documentation/static/pgpkeys/dch.key91
-rw-r--r--documentation/static/pgpkeys/def.key775
-rw-r--r--documentation/static/pgpkeys/des.key1121
-rw-r--r--documentation/static/pgpkeys/dfr.key44
-rw-r--r--documentation/static/pgpkeys/dmgk.key81
-rw-r--r--documentation/static/pgpkeys/dteske.key45
-rw-r--r--documentation/static/pgpkeys/dumbbell.key351
-rw-r--r--documentation/static/pgpkeys/dvl.key54
-rw-r--r--documentation/static/pgpkeys/ed.key54
-rw-r--r--documentation/static/pgpkeys/edwin.key45
-rw-r--r--documentation/static/pgpkeys/ehaupt.key52
-rw-r--r--documentation/static/pgpkeys/emaste.key67
-rw-r--r--documentation/static/pgpkeys/ericbsd.key45
-rw-r--r--documentation/static/pgpkeys/erj.key153
-rw-r--r--documentation/static/pgpkeys/erwin.key551
-rw-r--r--documentation/static/pgpkeys/flo.key142
-rw-r--r--documentation/static/pgpkeys/gahr.key130
-rw-r--r--documentation/static/pgpkeys/garys.key43
-rw-r--r--documentation/static/pgpkeys/gavin.key2360
-rw-r--r--documentation/static/pgpkeys/gblach.key53
-rw-r--r--documentation/static/pgpkeys/gleb.key53
-rw-r--r--documentation/static/pgpkeys/grembo.key49
-rw-r--r--documentation/static/pgpkeys/gshapiro.key727
-rw-r--r--documentation/static/pgpkeys/issyl0.key158
-rw-r--r--documentation/static/pgpkeys/ivadasz.key61
-rw-r--r--documentation/static/pgpkeys/jah.key53
-rw-r--r--documentation/static/pgpkeys/jase.key168
-rw-r--r--documentation/static/pgpkeys/jbeich.key53
-rw-r--r--documentation/static/pgpkeys/jeb.key45
-rw-r--r--documentation/static/pgpkeys/jgh.key87
-rw-r--r--documentation/static/pgpkeys/jh.key45
-rw-r--r--documentation/static/pgpkeys/jmcneill.key53
-rw-r--r--documentation/static/pgpkeys/jmd.key67
-rw-r--r--documentation/static/pgpkeys/joe.key123
-rw-r--r--documentation/static/pgpkeys/johalun.key57
-rw-r--r--documentation/static/pgpkeys/joneum.key45
-rw-r--r--documentation/static/pgpkeys/josef.key38
-rw-r--r--documentation/static/pgpkeys/jsm.key46
-rw-r--r--documentation/static/pgpkeys/jtl.key96
-rw-r--r--documentation/static/pgpkeys/junovitch.key53
-rw-r--r--documentation/static/pgpkeys/kai.key59
-rw-r--r--documentation/static/pgpkeys/kan.key95
-rw-r--r--documentation/static/pgpkeys/kd.key94
-rw-r--r--documentation/static/pgpkeys/kibab.key45
-rw-r--r--documentation/static/pgpkeys/kwm.key102
-rw-r--r--documentation/static/pgpkeys/laszlof.key41
-rw-r--r--documentation/static/pgpkeys/lev.key320
-rw-r--r--documentation/static/pgpkeys/lidl.key64
-rw-r--r--documentation/static/pgpkeys/lifanov.key67
-rw-r--r--documentation/static/pgpkeys/lioux.key142
-rw-r--r--documentation/static/pgpkeys/lippe.key44
-rw-r--r--documentation/static/pgpkeys/lme.key71
-rw-r--r--documentation/static/pgpkeys/lulf.key59
-rw-r--r--documentation/static/pgpkeys/luporl.key45
-rw-r--r--documentation/static/pgpkeys/lx.key36
-rw-r--r--documentation/static/pgpkeys/mahrens.key80
-rw-r--r--documentation/static/pgpkeys/mandree.key195
-rw-r--r--documentation/static/pgpkeys/marck.key1753
-rw-r--r--documentation/static/pgpkeys/matteo.key222
-rw-r--r--documentation/static/pgpkeys/matthew.key212
-rw-r--r--documentation/static/pgpkeys/mav.key158
-rw-r--r--documentation/static/pgpkeys/mckay.key66
-rw-r--r--documentation/static/pgpkeys/mdf.key58
-rw-r--r--documentation/static/pgpkeys/mhorne.key37
-rw-r--r--documentation/static/pgpkeys/mich.key56
-rw-r--r--documentation/static/pgpkeys/misha.key54
-rw-r--r--documentation/static/pgpkeys/mizhka.key44
-rw-r--r--documentation/static/pgpkeys/mjoras.key45
-rw-r--r--documentation/static/pgpkeys/mmokhi.key45
-rw-r--r--documentation/static/pgpkeys/mnag.key52
-rw-r--r--documentation/static/pgpkeys/mw.key44
-rw-r--r--documentation/static/pgpkeys/neel.key44
-rw-r--r--documentation/static/pgpkeys/netchild.key759
-rw-r--r--documentation/static/pgpkeys/oleg.key60
-rw-r--r--documentation/static/pgpkeys/olgeni.key423
-rw-r--r--documentation/static/pgpkeys/pgj.key130
-rw-r--r--documentation/static/pgpkeys/phil.key45
-rw-r--r--documentation/static/pgpkeys/philip.key153
-rw-r--r--documentation/static/pgpkeys/pizzamig.key45
-rw-r--r--documentation/static/pgpkeys/pjd.key114
-rw-r--r--documentation/static/pgpkeys/pkelsey.key80
-rw-r--r--documentation/static/pgpkeys/plosher.key104
-rw-r--r--documentation/static/pgpkeys/qingli.key45
-rw-r--r--documentation/static/pgpkeys/rakuco.key181
-rw-r--r--documentation/static/pgpkeys/rcyu.key45
-rw-r--r--documentation/static/pgpkeys/remko.key249
-rw-r--r--documentation/static/pgpkeys/rezny.key131
-rw-r--r--documentation/static/pgpkeys/rigoletto.key61
-rw-r--r--documentation/static/pgpkeys/rik.key49
-rw-r--r--documentation/static/pgpkeys/rpokala.key74
-rw-r--r--documentation/static/pgpkeys/rrs.key44
-rw-r--r--documentation/static/pgpkeys/rstone.key45
-rw-r--r--documentation/static/pgpkeys/ru.key94
-rw-r--r--documentation/static/pgpkeys/salvadore.key90
-rw-r--r--documentation/static/pgpkeys/sbruno.key46
-rw-r--r--documentation/static/pgpkeys/sbz.key44
-rw-r--r--documentation/static/pgpkeys/schweikh.key42
-rw-r--r--documentation/static/pgpkeys/seanc.key54
-rw-r--r--documentation/static/pgpkeys/sef.key108
-rw-r--r--documentation/static/pgpkeys/sephe.key45
-rw-r--r--documentation/static/pgpkeys/sevan.key786
-rw-r--r--documentation/static/pgpkeys/sg.key331
-rw-r--r--documentation/static/pgpkeys/shurd.key44
-rw-r--r--documentation/static/pgpkeys/skra.key53
-rw-r--r--documentation/static/pgpkeys/skreuzer.key63
-rw-r--r--documentation/static/pgpkeys/slavash.key64
-rw-r--r--documentation/static/pgpkeys/slm.key44
-rw-r--r--documentation/static/pgpkeys/stas.key87
-rw-r--r--documentation/static/pgpkeys/stefanf.key54
-rw-r--r--documentation/static/pgpkeys/swills.key61
-rw-r--r--documentation/static/pgpkeys/thierry.key838
-rw-r--r--documentation/static/pgpkeys/thj.key228
-rw-r--r--documentation/static/pgpkeys/tijl.key97
-rw-r--r--documentation/static/pgpkeys/tj.key67
-rw-r--r--documentation/static/pgpkeys/tmunro.key45
-rw-r--r--documentation/static/pgpkeys/tobik.key33
-rw-r--r--documentation/static/pgpkeys/trasz.key46
-rw-r--r--documentation/static/pgpkeys/truckman.key45
-rw-r--r--documentation/static/pgpkeys/tsoome.key44
-rw-r--r--documentation/static/pgpkeys/ultima.key45
-rw-r--r--documentation/static/pgpkeys/uqs.key137
-rw-r--r--documentation/static/pgpkeys/vangyzen.key53
-rw-r--r--documentation/static/pgpkeys/wblock.key54
-rw-r--r--documentation/static/pgpkeys/wma.key44
-rw-r--r--documentation/static/pgpkeys/woodsb02.key53
-rw-r--r--documentation/static/pgpkeys/wulf.key55
-rw-r--r--documentation/static/pgpkeys/xmj.key53
-rw-r--r--documentation/static/pgpkeys/ygy.key106
-rw-r--r--documentation/static/pgpkeys/yongari.key53
-rw-r--r--documentation/static/pgpkeys/yuri.key45
-rw-r--r--documentation/static/pgpkeys/yuripv.key68
-rw-r--r--documentation/static/pgpkeys/zbb.key43
-rw-r--r--documentation/static/pgpkeys/zont.key100
-rw-r--r--documentation/themes/beastie/assets/js/copy-clipboard.js69
-rw-r--r--documentation/themes/beastie/assets/js/search.js65
-rw-r--r--documentation/themes/beastie/assets/js/theme-chooser.js40
-rw-r--r--documentation/themes/beastie/assets/styles/documentation.scss58
-rw-r--r--documentation/themes/beastie/assets/styles/footer.scss21
-rw-r--r--documentation/themes/beastie/assets/styles/global.scss108
-rw-r--r--documentation/themes/beastie/assets/styles/header.scss10
-rw-r--r--documentation/themes/beastie/assets/styles/variables.scss10
-rw-r--r--documentation/themes/beastie/i18n/bn-bd.toml9
-rw-r--r--documentation/themes/beastie/i18n/da.toml9
-rw-r--r--documentation/themes/beastie/i18n/de.toml9
-rw-r--r--documentation/themes/beastie/i18n/el.toml9
-rw-r--r--documentation/themes/beastie/i18n/en.toml9
-rw-r--r--documentation/themes/beastie/i18n/es.toml9
-rw-r--r--documentation/themes/beastie/i18n/fr.toml9
-rw-r--r--documentation/themes/beastie/i18n/hu.toml9
-rw-r--r--documentation/themes/beastie/i18n/it.toml109
-rw-r--r--documentation/themes/beastie/i18n/ja.toml35
-rw-r--r--documentation/themes/beastie/i18n/ko.toml9
-rw-r--r--documentation/themes/beastie/i18n/mn.toml9
-rw-r--r--documentation/themes/beastie/i18n/nl.toml9
-rw-r--r--documentation/themes/beastie/i18n/pl.toml9
-rw-r--r--documentation/themes/beastie/i18n/pt-br.toml9
-rw-r--r--documentation/themes/beastie/i18n/ru.toml9
-rw-r--r--documentation/themes/beastie/i18n/tr.toml9
-rw-r--r--documentation/themes/beastie/i18n/zh-cn.toml9
-rw-r--r--documentation/themes/beastie/i18n/zh-tw.toml87
-rw-r--r--documentation/themes/beastie/layouts/_default/baseof.html2
-rw-r--r--documentation/themes/beastie/layouts/articles/list.html29
-rw-r--r--documentation/themes/beastie/layouts/articles/single.html29
-rw-r--r--documentation/themes/beastie/layouts/books/list.html68
-rw-r--r--documentation/themes/beastie/layouts/books/single.html68
-rw-r--r--documentation/themes/beastie/layouts/partials/menu.html23
-rwxr-xr-xdocumentation/themes/beastie/layouts/partials/site-footer.html118
-rw-r--r--documentation/themes/beastie/layouts/partials/site-head.html90
-rwxr-xr-xdocumentation/themes/beastie/layouts/partials/site-header.html16
-rw-r--r--documentation/themes/beastie/layouts/partials/trademarks.html10
-rw-r--r--shared/attributes/attributes-id.adoc9
-rw-r--r--shared/authors.adoc8
-rw-r--r--shared/contrib-additional.adoc4
-rw-r--r--shared/contrib-committers.adoc9
-rw-r--r--shared/contrib-corealumni.adoc14
-rw-r--r--shared/contrib-develalumni.adoc10
-rw-r--r--shared/en/mailing-lists.adoc4
-rw-r--r--shared/id/mailing-lists.adoc654
-rw-r--r--shared/id/teams.adoc84
-rw-r--r--shared/id/urls.adoc63
-rw-r--r--shared/ja/mailing-lists.adoc76
-rw-r--r--shared/mirrors.adoc6
-rw-r--r--shared/pt-br/mailing-lists.adoc28
-rw-r--r--shared/releases.adoc16
-rwxr-xr-xtools/translate.sh2
-rwxr-xr-xtools/update_translate_template.sh2
-rw-r--r--website/Makefile9
-rw-r--r--website/archetypes/release/hardware.adoc90
-rw-r--r--website/config/_default/config.toml4
-rw-r--r--website/config/_default/languages.fr.toml2
-rw-r--r--website/content/de/releases/4.11r/announce.html1
-rw-r--r--website/content/de/releases/4.11r/hardware.html1
-rw-r--r--website/content/de/releases/4.11r/installation.html1
-rw-r--r--website/content/de/releases/4.11r/relnotes.html1
-rw-r--r--website/content/de/releases/4.6.2r/announce.html1
-rw-r--r--website/content/de/releases/4.6.2r/hardware.html1
-rw-r--r--website/content/de/releases/4.6.2r/relnotes.html1
-rw-r--r--website/content/de/releases/4.7r/announce.html1
-rw-r--r--website/content/de/releases/4.7r/hardware.html1
-rw-r--r--website/content/de/releases/4.7r/installation.html1
-rw-r--r--website/content/de/releases/4.7r/relnotes.html1
-rw-r--r--website/content/de/releases/4.8r/announce.html1
-rw-r--r--website/content/de/releases/4.8r/hardware.html1
-rw-r--r--website/content/de/releases/4.8r/installation.html1
-rw-r--r--website/content/de/releases/4.8r/relnotes.html1
-rw-r--r--website/content/de/releases/4.9r/announce.html2
-rw-r--r--website/content/de/releases/4.9r/hardware.html2
-rw-r--r--website/content/de/releases/4.9r/installation.html2
-rw-r--r--website/content/de/releases/4.9r/relnotes.html2
-rw-r--r--website/content/de/releases/5.0r/announce.html2
-rw-r--r--website/content/de/releases/5.0r/hardware.html2
-rw-r--r--website/content/de/releases/5.0r/installation.html2
-rw-r--r--website/content/de/releases/5.0r/relnotes.html2
-rw-r--r--website/content/de/releases/5.1r/announce.html2
-rw-r--r--website/content/de/releases/5.1r/hardware.html2
-rw-r--r--website/content/de/releases/5.1r/installation.html2
-rw-r--r--website/content/de/releases/5.1r/relnotes.html2
-rw-r--r--website/content/de/releases/5.2r/hardware.html2
-rw-r--r--website/content/de/releases/5.2r/installation.html2
-rw-r--r--website/content/de/releases/5.2r/relnotes.html2
-rw-r--r--website/content/de/releases/5.3r/announce.html2
-rw-r--r--website/content/de/releases/5.3r/hardware.html2
-rw-r--r--website/content/de/releases/5.3r/installation.html2
-rw-r--r--website/content/de/releases/5.3r/relnotes.html2
-rw-r--r--website/content/de/where.adoc268
-rw-r--r--website/content/en/administration.adoc59
-rw-r--r--website/content/en/advocacy/_index.adoc38
-rw-r--r--website/content/en/advocacy/myths.adoc60
-rw-r--r--website/content/en/applications.adoc4
-rw-r--r--website/content/en/cgi/cgi-style.pl6
-rwxr-xr-xwebsite/content/en/cgi/man.cgi42
-rwxr-xr-xwebsite/content/en/cgi/mid.cgi2
-rwxr-xr-xwebsite/content/en/cgi/ports.cgi6
-rw-r--r--website/content/en/commercial/hardware.adoc2
-rw-r--r--website/content/en/community/_index.adoc4
-rw-r--r--website/content/en/copyright/trademarks.adoc4
-rw-r--r--website/content/en/docs/webresources.adoc4
-rw-r--r--website/content/en/donations/donors.adoc6
-rw-r--r--website/content/en/events/2003.adoc1
-rw-r--r--website/content/en/events/2004.adoc1
-rw-r--r--website/content/en/events/2005.adoc1
-rw-r--r--website/content/en/events/2006.adoc1
-rw-r--r--website/content/en/events/2007.adoc1
-rw-r--r--website/content/en/events/2008.adoc1
-rw-r--r--website/content/en/events/2009.adoc1
-rw-r--r--website/content/en/events/2010.adoc1
-rw-r--r--website/content/en/events/2011.adoc1
-rw-r--r--website/content/en/events/2012.adoc1
-rw-r--r--website/content/en/events/2013.adoc1
-rw-r--r--website/content/en/events/2014.adoc1
-rw-r--r--website/content/en/events/2015.adoc1
-rw-r--r--website/content/en/events/2016.adoc1
-rw-r--r--website/content/en/events/2017.adoc1
-rw-r--r--website/content/en/events/2018.adoc1
-rw-r--r--website/content/en/events/2019.adoc11
-rw-r--r--website/content/en/internal/bylaws.adoc2
-rw-r--r--website/content/en/internal/clusteradm.adoc4
-rw-r--r--website/content/en/internal/code-of-conduct.adoc2
-rw-r--r--website/content/en/internal/machines.adoc6
-rw-r--r--website/content/en/internal/members.adoc24
-rw-r--r--website/content/en/internal/new-account.adoc29
-rw-r--r--website/content/en/layout/js/google.js52
-rw-r--r--website/content/en/portmgr/policies_eol.adoc17
-rw-r--r--website/content/en/ports/installing.adoc2
-rw-r--r--website/content/en/press/press-rel-9.adoc2
-rw-r--r--website/content/en/privacy.adoc4
-rw-r--r--website/content/en/projects/_index.adoc1
-rw-r--r--website/content/en/projects/summerofcode.adoc82
-rw-r--r--website/content/en/releases/12.2R/errata.adoc8
-rw-r--r--website/content/en/releases/12.3R/errata.adoc16
-rw-r--r--website/content/en/releases/13.0R/errata.adoc20
-rw-r--r--website/content/en/releases/13.1R/_index.adoc29
-rw-r--r--website/content/en/releases/13.1R/announce.adoc626
-rw-r--r--website/content/en/releases/13.1R/announce.asc659
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-amd64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-amd64.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm-armv6-RPI-B.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64-LTS.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-PINEBOOK.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-ROCK64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-ROCKPRO64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-arm64-aarch64.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-i386-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-i386.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-powerpc-powerpc64.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-powerpc-powerpc64le.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-powerpc-powerpcspe.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-powerpc.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-riscv-riscv64-GENERICSD.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-riscv-riscv64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA256-FreeBSD-13.1-RELEASE-riscv-riscv64.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-amd64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-amd64.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm-armv6-RPI-B.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64-LTS.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-PINEBOOK.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-ROCK64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-ROCKPRO64.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-arm64-aarch64.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-i386-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-i386.asc29
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-powerpc-powerpc64.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-powerpc-powerpc64le.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-powerpc-powerpcspe.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-powerpc.asc25
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-riscv-riscv64-GENERICSD.asc20
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-riscv-riscv64-vm.asc23
-rw-r--r--website/content/en/releases/13.1R/checksums/CHECKSUM.SHA512-FreeBSD-13.1-RELEASE-riscv-riscv64.asc29
-rw-r--r--website/content/en/releases/13.1R/errata.adoc105
-rw-r--r--website/content/en/releases/13.1R/hardware.adoc3886
-rw-r--r--website/content/en/releases/13.1R/installation.adoc84
-rw-r--r--website/content/en/releases/13.1R/readme.adoc133
-rw-r--r--website/content/en/releases/13.1R/relnotes.adoc435
-rw-r--r--website/content/en/releases/13.1R/schedule.adoc56
-rw-r--r--website/content/en/releases/13.1R/signatures.adoc65
-rw-r--r--website/content/en/releases/5.0R/DP1/announce.html2
-rw-r--r--website/content/en/releases/5.0R/DP1/hardware.html2
-rw-r--r--website/content/en/releases/5.0R/DP1/installation.html2
-rw-r--r--website/content/en/releases/5.0R/DP1/relnotes.html2
-rw-r--r--website/content/en/releases/5.0R/DP2/announce.html2
-rw-r--r--website/content/en/releases/5.0R/DP2/hardware.html2
-rw-r--r--website/content/en/releases/5.0R/DP2/installation.html2
-rw-r--r--website/content/en/releases/5.0R/DP2/relnotes.html2
-rw-r--r--website/content/en/releases/_index.adoc7
-rw-r--r--website/content/en/releng/_index.adoc9
-rw-r--r--website/content/en/relnotes.adoc29
-rw-r--r--website/content/en/security/_index.adoc6
-rw-r--r--website/content/en/security/unsupported.adoc1
-rw-r--r--website/content/en/snapshots/_index.adoc4
-rw-r--r--website/content/en/status/README90
-rw-r--r--website/content/en/status/_index.adoc7
-rw-r--r--website/content/en/status/report-2001-06.html2
-rw-r--r--website/content/en/status/report-2001-07.html2
-rw-r--r--website/content/en/status/report-2001-08.html2
-rw-r--r--website/content/en/status/report-2001-09.html2
-rw-r--r--website/content/en/status/report-2001-11.html2
-rw-r--r--website/content/en/status/report-2001-12-2002-01.html2
-rw-r--r--website/content/en/status/report-2002-02-2002-04.html2
-rw-r--r--website/content/en/status/report-2002-05-2002-06.html2
-rw-r--r--website/content/en/status/report-2002-07-2002-08.html2
-rw-r--r--website/content/en/status/report-2002-09-2002-10.html2
-rw-r--r--website/content/en/status/report-2002-11-2002-12.html2
-rw-r--r--website/content/en/status/report-2003-01-2003-02.html2
-rw-r--r--website/content/en/status/report-2003-03-2003-09.html2
-rw-r--r--website/content/en/status/report-2003-10-2003-12.html2
-rw-r--r--website/content/en/status/report-2004-01-2004-02.html2
-rw-r--r--website/content/en/status/report-2004-03-2004-04.html2
-rw-r--r--website/content/en/status/report-2004-05-2004-06.html2
-rw-r--r--website/content/en/status/report-2004-07-2004-12.html93
-rw-r--r--website/content/en/status/report-2005-01-2005-03.html2
-rw-r--r--website/content/en/status/report-2005-03-2005-06.html2
-rw-r--r--website/content/en/status/report-2005-07-2005-10.html2
-rw-r--r--website/content/en/status/report-2005-10-2005-12.html2
-rw-r--r--website/content/en/status/report-2006-01-2006-03.html2
-rw-r--r--website/content/en/status/report-2006-04-2006-06.html2
-rw-r--r--website/content/en/status/report-2006-06-2006-10.html2
-rw-r--r--website/content/en/status/report-2006-10-2006-12.html2
-rw-r--r--website/content/en/status/report-2007-01-2007-03.html2
-rw-r--r--website/content/en/status/report-2007-04-2007-06.html2
-rw-r--r--website/content/en/status/report-2007-07-2007-10.html2
-rw-r--r--website/content/en/status/report-2007-10-2007-12.html2
-rw-r--r--website/content/en/status/report-2008-01-2008-03.html2
-rw-r--r--website/content/en/status/report-2008-04-2008-06.html2
-rw-r--r--website/content/en/status/report-2008-07-2008-09.html2
-rw-r--r--website/content/en/status/report-2008-10-2008-12.html2
-rw-r--r--website/content/en/status/report-2009-01-2009-03.html2
-rw-r--r--website/content/en/status/report-2009-04-2009-09.html139
-rw-r--r--website/content/en/status/report-2009-10-2009-12.html109
-rw-r--r--website/content/en/status/report-2010-01-2010-03.html127
-rw-r--r--website/content/en/status/report-2010-04-2010-06.html6
-rw-r--r--website/content/en/status/report-2010-07-2010-09.html2
-rw-r--r--website/content/en/status/report-2010-10-2010-12.html2
-rw-r--r--website/content/en/status/report-2011-01-2011-03.html2
-rw-r--r--website/content/en/status/report-2011-04-2011-06.html2
-rw-r--r--website/content/en/status/report-2011-07-2011-09.html2
-rw-r--r--website/content/en/status/report-2011-10-2011-12.html2
-rw-r--r--website/content/en/status/report-2012-01-2012-03.html2
-rw-r--r--website/content/en/status/report-2012-04-2012-06.html6
-rw-r--r--website/content/en/status/report-2012-07-2012-09.html4
-rw-r--r--website/content/en/status/report-2012-10-2012-12.html2
-rw-r--r--website/content/en/status/report-2013-01-2013-03.html2
-rw-r--r--website/content/en/status/report-2013-04-2013-06.html2
-rw-r--r--website/content/en/status/report-2013-05-devsummit.html2
-rw-r--r--website/content/en/status/report-2013-07-2013-09.html10
-rw-r--r--website/content/en/status/report-2013-09-devsummit.html2
-rw-r--r--website/content/en/status/report-2013-10-2013-12.html16
-rw-r--r--website/content/en/status/report-2014-01-2014-03.html12
-rw-r--r--website/content/en/status/report-2014-04-2014-06.html8
-rw-r--r--website/content/en/status/report-2014-07-2014-09.html2
-rw-r--r--website/content/en/status/report-2014-10-2014-12.html4
-rw-r--r--website/content/en/status/report-2015-01-2015-03.html4
-rw-r--r--website/content/en/status/report-2015-04-2015-06.html2
-rw-r--r--website/content/en/status/report-2015-07-2015-09.html147
-rw-r--r--website/content/en/status/report-2015-10-2015-12.html2
-rw-r--r--website/content/en/status/report-2016-01-2016-03.html2
-rw-r--r--website/content/en/status/report-2016-04-2016-06.html2
-rw-r--r--website/content/en/status/report-2016-07-2016-09.html2
-rw-r--r--website/content/en/status/report-2016-10-2016-12.html2
-rw-r--r--website/content/en/status/report-2017-01-2017-03.html2
-rw-r--r--website/content/en/status/report-2017-04-2017-06.html2
-rw-r--r--website/content/en/status/report-2017-07-2017-09.html2
-rw-r--r--website/content/en/status/report-2017-10-2017-12.html2
-rw-r--r--website/content/en/status/report-2018-01-2018-09.html2
-rw-r--r--website/content/en/status/report-2018-09-2018-12.html2
-rw-r--r--website/content/en/status/report-2019-01-2019-03.html2
-rw-r--r--website/content/en/status/report-2019-04-2019-06.html2
-rw-r--r--website/content/en/status/report-2019-07-2019-09.html2
-rw-r--r--website/content/en/status/report-2019-10-2019-12.html2
-rw-r--r--website/content/en/status/report-2020-01-2020-03.html2
-rw-r--r--website/content/en/status/report-2020-04-2020-06.html43
-rw-r--r--website/content/en/status/report-2020-07-2020-09.html2
-rw-r--r--website/content/en/status/report-2020-10-2020-12.html2
-rw-r--r--website/content/en/status/report-2021-01-2021-03/_index.adoc2
-rw-r--r--website/content/en/status/report-2021-04-2021-06/_index.adoc2
-rw-r--r--website/content/en/status/report-2021-10-2021-12/_index.adoc131
-rw-r--r--website/content/en/status/report-2021-10-2021-12/aslr.adoc29
-rw-r--r--website/content/en/status/report-2021-10-2021-12/avx-bug.adoc30
-rw-r--r--website/content/en/status/report-2021-10-2021-12/boot-performance.adoc33
-rw-r--r--website/content/en/status/report-2021-10-2021-12/doceng.adoc39
-rw-r--r--website/content/en/status/report-2021-10-2021-12/ena.adoc26
-rw-r--r--website/content/en/status/report-2021-10-2021-12/freebsd-foundation.adoc151
-rw-r--r--website/content/en/status/report-2021-10-2021-12/hellosystem.adoc27
-rw-r--r--website/content/en/status/report-2021-10-2021-12/iwlwifi.adoc23
-rw-r--r--website/content/en/status/report-2021-10-2021-12/kde.adoc38
-rw-r--r--website/content/en/status/report-2021-10-2021-12/lldb.adoc40
-rw-r--r--website/content/en/status/report-2021-10-2021-12/ls1027a.adoc35
-rw-r--r--website/content/en/status/report-2021-10-2021-12/membarrier-rseq.adoc103
-rw-r--r--website/content/en/status/report-2021-10-2021-12/ocf-wg.adoc20
-rw-r--r--website/content/en/status/report-2021-10-2021-12/office.adoc26
-rw-r--r--website/content/en/status/report-2021-10-2021-12/openssh.adoc25
-rw-r--r--website/content/en/status/report-2021-10-2021-12/portmgr.adoc36
-rw-r--r--website/content/en/status/report-2021-10-2021-12/pot.adoc28
-rw-r--r--website/content/en/status/report-2021-10-2021-12/vdso.adoc82
-rw-r--r--website/content/en/status/report-2021-10-2021-12/www.adoc25
-rw-r--r--website/content/en/status/report-2022-01-2022-03/_index.adoc152
-rw-r--r--website/content/en/status/report-2022-01-2022-03/accessibility.adoc20
-rw-r--r--website/content/en/status/report-2022-01-2022-03/boot-performance.adoc28
-rw-r--r--website/content/en/status/report-2022-01-2022-03/ci.adoc53
-rw-r--r--website/content/en/status/report-2022-01-2022-03/clusteradm.adoc49
-rw-r--r--website/content/en/status/report-2022-01-2022-03/doceng.adoc100
-rw-r--r--website/content/en/status/report-2022-01-2022-03/dpaa2.adoc32
-rw-r--r--website/content/en/status/report-2022-01-2022-03/ena.adoc26
-rw-r--r--website/content/en/status/report-2022-01-2022-03/fpart.adoc38
-rw-r--r--website/content/en/status/report-2022-01-2022-03/freebsd-foundation.adoc145
-rw-r--r--website/content/en/status/report-2022-01-2022-03/gcc.adoc28
-rw-r--r--website/content/en/status/report-2022-01-2022-03/gunion.adoc23
-rw-r--r--website/content/en/status/report-2022-01-2022-03/hellosystem.adoc28
-rw-r--r--website/content/en/status/report-2022-01-2022-03/intro.adoc11
-rw-r--r--website/content/en/status/report-2022-01-2022-03/iwlwifi.adoc26
-rw-r--r--website/content/en/status/report-2022-01-2022-03/kde.adoc52
-rw-r--r--website/content/en/status/report-2022-01-2022-03/ocf-wg.adoc14
-rw-r--r--website/content/en/status/report-2022-01-2022-03/office.adoc24
-rw-r--r--website/content/en/status/report-2022-01-2022-03/portconfig.adoc18
-rw-r--r--website/content/en/status/report-2022-01-2022-03/portmgr.adoc51
-rw-r--r--website/content/en/status/report-2022-01-2022-03/pot.adoc23
-rw-r--r--website/content/en/status/report-2022-01-2022-03/releng.adoc21
-rw-r--r--website/content/en/status/report-2022-01-2022-03/rtw88.adoc24
-rw-r--r--website/content/en/status/report-2022-01-2022-03/wifibox.adoc31
-rw-r--r--website/content/en/where.adoc261
-rw-r--r--website/content/es/where.adoc270
-rw-r--r--website/content/fr/gnome/docs/bugging.adoc2
-rw-r--r--website/content/fr/internal/bylaws.adoc4
-rw-r--r--website/content/fr/where.adoc368
-rw-r--r--website/content/hu/where.adoc351
-rw-r--r--website/content/it/where.adoc352
-rw-r--r--website/content/ja/community/mailinglists.adoc2
-rw-r--r--website/content/ja/internal/machines.adoc12
-rw-r--r--website/content/ja/platforms/_index.adoc38
-rw-r--r--website/content/ja/projects/newbies.adoc8
-rw-r--r--website/content/ja/releases/_index.adoc11
-rw-r--r--website/content/ja/relnotes.adoc46
-rw-r--r--website/content/ja/security/_index.adoc6
-rw-r--r--website/content/ja/security/unsupported.adoc2
-rw-r--r--website/content/ja/snapshots/_index.adoc35
-rw-r--r--website/content/ja/where.adoc250
-rw-r--r--website/content/nl/where.adoc225
-rw-r--r--website/content/ru/internal/bylaws.adoc4
-rw-r--r--website/content/ru/releases/5.3R/announce.html2
-rw-r--r--website/content/ru/releases/5.3R/hardware.html2
-rw-r--r--website/content/ru/releases/5.3R/installation.html2
-rw-r--r--website/content/ru/releases/5.3R/relnotes.html2
-rw-r--r--website/content/ru/releases/5.4R/announce.html2
-rw-r--r--website/content/ru/releases/5.4R/hardware.html2
-rw-r--r--website/content/ru/releases/5.4R/installation.html2
-rw-r--r--website/content/ru/releases/5.4R/relnotes.html2
-rw-r--r--website/content/ru/where.adoc346
-rw-r--r--website/content/zh-cn/releases/5.4r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/5.4r/installation.html2
-rw-r--r--website/content/zh-cn/releases/5.4r/relnotes.html2
-rw-r--r--website/content/zh-cn/releases/5.5r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/5.5r/installation.html2
-rw-r--r--website/content/zh-cn/releases/5.5r/relnotes.html2
-rw-r--r--website/content/zh-cn/releases/6.0r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/6.0r/installation.html2
-rw-r--r--website/content/zh-cn/releases/6.0r/relnotes.html2
-rw-r--r--website/content/zh-cn/releases/6.1r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/6.1r/installation.html2
-rw-r--r--website/content/zh-cn/releases/6.2r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/6.2r/installation.html2
-rw-r--r--website/content/zh-cn/releases/6.2r/relnotes.html2
-rw-r--r--website/content/zh-cn/releases/6.3r/hardware.html2
-rw-r--r--website/content/zh-cn/releases/6.3r/installation.html2
-rw-r--r--website/content/zh-cn/releases/6.3r/relnotes.html2
-rw-r--r--website/content/zh-cn/where.adoc336
-rw-r--r--website/content/zh-tw/where.adoc320
-rw-r--r--website/data/en/events/events2014.toml2
-rw-r--r--website/data/en/events/events2022.toml46
-rw-r--r--website/data/en/news/news.toml78
-rw-r--r--website/data/en/usergroups/usergroups.toml7
-rw-r--r--website/data/en/vendors/consulting.toml21
-rw-r--r--website/data/en/vendors/isp.toml6
-rw-r--r--website/data/fr/news/news.toml139
-rw-r--r--website/data/ja/news/news.toml78
-rw-r--r--website/data/security/advisories.toml28
-rw-r--r--website/data/security/errata.toml36
-rw-r--r--website/data/zh-tw/news/news.toml43
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:07.la57.asc130
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:08.i386.asc125
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:09.freebsd-update.asc125
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:10.zfs.asc134
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:11.zfs.asc141
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:12.zfs.asc128
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:13.zfs.asc127
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:14.tzdata.asc176
-rw-r--r--website/static/security/advisories/FreeBSD-EN-22:15.pf.asc128
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:02.wifi.asc165
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:03.openssl.asc153
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:04.netmap.asc155
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:05.bhyve.asc160
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:06.ioctl.asc153
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:07.wifi_meshid.asc147
-rw-r--r--website/static/security/advisories/FreeBSD-SA-22:08.zlib.asc155
-rw-r--r--website/static/security/advisory-template.txt8
-rw-r--r--website/static/security/errata-template.txt8
-rw-r--r--website/static/security/patches/EN-22:07/la57.patch12
-rw-r--r--website/static/security/patches/EN-22:07/la57.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:08/i386.patch13
-rw-r--r--website/static/security/patches/EN-22:08/i386.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:09/freebsd-update.patch25
-rw-r--r--website/static/security/patches/EN-22:09/freebsd-update.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:10/zfs.patch45
-rw-r--r--website/static/security/patches/EN-22:10/zfs.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:11/zfs.patch199
-rw-r--r--website/static/security/patches/EN-22:11/zfs.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:12/zfs.patch44
-rw-r--r--website/static/security/patches/EN-22:12/zfs.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:13/zfs.patch11
-rw-r--r--website/static/security/patches/EN-22:13/zfs.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:14/tzdata-2022a.patch3142
-rw-r--r--website/static/security/patches/EN-22:14/tzdata-2022a.patch.asc16
-rw-r--r--website/static/security/patches/EN-22:15/pf.patch25
-rw-r--r--website/static/security/patches/EN-22:15/pf.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:02/wifi.12.patch389
-rw-r--r--website/static/security/patches/SA-22:02/wifi.12.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:02/wifi.13.patch367
-rw-r--r--website/static/security/patches/SA-22:02/wifi.13.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:03/openssl.patch92
-rw-r--r--website/static/security/patches/SA-22:03/openssl.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:04/netmap.patch70
-rw-r--r--website/static/security/patches/SA-22:04/netmap.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:05/bhyve.patch26
-rw-r--r--website/static/security/patches/SA-22:05/bhyve.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:06/ioctl.patch108
-rw-r--r--website/static/security/patches/SA-22:06/ioctl.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:07/wifi_meshid.patch15
-rw-r--r--website/static/security/patches/SA-22:07/wifi_meshid.patch.asc16
-rw-r--r--website/static/security/patches/SA-22:08/zlib.patch308
-rw-r--r--website/static/security/patches/SA-22:08/zlib.patch.asc16
-rw-r--r--website/themes/beastie/i18n/de.toml3
-rw-r--r--website/themes/beastie/i18n/en.toml9
-rw-r--r--website/themes/beastie/i18n/es.toml3
-rw-r--r--website/themes/beastie/i18n/fr.toml3
-rw-r--r--website/themes/beastie/i18n/ja.toml36
-rw-r--r--website/themes/beastie/i18n/nl.toml3
-rw-r--r--website/themes/beastie/i18n/ru.toml3
-rw-r--r--website/themes/beastie/i18n/zh-cn.toml3
-rw-r--r--website/themes/beastie/i18n/zh-tw.toml3
-rw-r--r--website/themes/beastie/layouts/_default/list.html6
-rw-r--r--website/themes/beastie/layouts/_default/single.html6
-rw-r--r--website/themes/beastie/layouts/commercial/list.html6
-rw-r--r--website/themes/beastie/layouts/commercial/single.html6
-rw-r--r--website/themes/beastie/layouts/events/list.html41
-rw-r--r--website/themes/beastie/layouts/events/list.ics19
-rw-r--r--website/themes/beastie/layouts/events/single.html41
-rwxr-xr-xwebsite/themes/beastie/layouts/index.html7
-rw-r--r--website/themes/beastie/layouts/news/list.html6
-rw-r--r--website/themes/beastie/layouts/news/single.html6
-rw-r--r--website/themes/beastie/layouts/partials/sidenav.html21
-rw-r--r--website/themes/beastie/layouts/partials/site-head.html1
-rw-r--r--website/themes/beastie/layouts/partials/site-navigation.html3
-rw-r--r--website/themes/beastie/layouts/press/list.html6
-rw-r--r--website/themes/beastie/layouts/press/single.html6
-rw-r--r--website/themes/beastie/layouts/security/list.html6
-rw-r--r--website/themes/beastie/layouts/security/single.html6
-rw-r--r--website/themes/beastie/layouts/shortcodes/form-search-mail.html2
-rw-r--r--website/themes/beastie/layouts/usergroups/section.html7
-rw-r--r--website/themes/beastie/static/css/layout.css2
-rw-r--r--website/themes/beastie/static/js/google.js52
777 files changed, 41088 insertions, 26653 deletions
diff --git a/.cirrus.yml b/.cirrus.yml
index f5478f7be3..e828d58f33 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -9,5 +9,5 @@ task:
install_script:
- pkg install -y docproj
test_script:
- - make HUGO_ARGS="--verbose --debug --path-warnings"
+ - make HUGO_ARGS="--verbose --debug"
diff --git a/documentation/Makefile b/documentation/Makefile
index ac2738450d..457f6add0b 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -24,12 +24,12 @@
MAINTAINER=carlavilla@FreeBSD.org
# List of languages without book translations
-ARTICLEONLY_LANGS= bn-bd da ko tr
+ARTICLEONLY_LANGS= bn-bd da id ko tr
# List of languages without article translations
BOOKONLY_LANGS= mn
# List of all languages we have content for
-ALL_LANGUAGES= bn-bd da de el en es fr hu it ja ko mn nl pl pt-br ru tr zh-cn zh-tw
+ALL_LANGUAGES= bn-bd da de el en es fr hu id it ja ko mn nl pl pt-br ru tr zh-cn zh-tw
LOCALBASE?= /usr/local
diff --git a/documentation/config/_default/config.toml b/documentation/config/_default/config.toml
index 17f8bb41dd..087c0f5576 100644
--- a/documentation/config/_default/config.toml
+++ b/documentation/config/_default/config.toml
@@ -11,13 +11,14 @@ disableKinds = [ "taxonomy", "taxonomyTerm" ]
authors = [ "carlavilla@FreeBSD.org" ]
ignoreFiles = [ "chapter.adoc$", "contrib-386bsd.adoc$", "contrib-additional.adoc$", "contrib-committers.adoc$", "contrib-corealumni.adoc$", "contrib-develalumni.adoc$", "contrib-develinmemoriam.adoc$", "contrib-portmgralumni.adoc$", "\\.po$" ]
enableRobotsTXT = true
-googleAnalytics = 'UA-22767463-1'
+enableGitInfo = true
[params]
websiteURL = "https://www.FreeBSD.org"
description = "FreeBSD Documentation Portal"
isOnline = true
editBaseUrl = "https://github.com/freebsd/freebsd-doc/edit/main/documentation/content/"
+ downloadBaseUrl = "https://download.freebsd.org/doc/"
[security]
enableInlineShortcodes = false
diff --git a/documentation/config/_default/languages.id.toml b/documentation/config/_default/languages.id.toml
new file mode 100644
index 0000000000..e576406cba
--- /dev/null
+++ b/documentation/config/_default/languages.id.toml
@@ -0,0 +1,4 @@
+title = "FreeBSD Documentation Portal"
+contentDir = "content/id"
+languageName = "Indonesian"
+weight = 20
diff --git a/documentation/config/offline/config.toml b/documentation/config/offline/config.toml
index f359e2ad7e..653ef5b279 100644
--- a/documentation/config/offline/config.toml
+++ b/documentation/config/offline/config.toml
@@ -1,6 +1,6 @@
# FreeBSD documentation
-baseURL = "localhost"
+baseURL = ""
title = "FreeBSD Documentation Portal"
copyright = "BSD 2-clause 'Simplified' License"
defaultContentLanguage = "en"
@@ -11,6 +11,7 @@ disableKinds = [ "taxonomy", "term", "RSS", "sitemap", "robotsTXT", "404" ]
authors = [ "carlavilla@FreeBSD.org" ]
ignoreFiles = [ "chapter.adoc$", "contrib-386bsd.adoc$", "contrib-additional.adoc$", "contrib-committers.adoc$", "contrib-corealumni.adoc$", "contrib-develalumni.adoc$", "contrib-develinmemoriam.adoc$", "contrib-portmgralumni.adoc$", "books.adoc$", "\\.po$" ]
enableRobotsTXT = true
+relativeURLs = true
[params]
websiteURL = "https://www.FreeBSD.org"
@@ -29,11 +30,11 @@ enableRobotsTXT = true
urls = [".*"]
[markup.asciidocExt]
- extensions = ["man-macro", "inter-document-references-macro", "cross-document-references-macro", "sectnumoffset-treeprocessor", "packages-macro", "git-macro"]
- [markup.asciidocExt.attributes]
- env-beastie = true
- isOnline = false
- skip-front-matter = true
+ extensions = ["man-macro", "inter-document-references-macro", "cross-document-references-macro", "sectnumoffset-treeprocessor", "packages-macro", "git-macro"]
+ [markup.asciidocExt.attributes]
+ env-beastie = true
+ isOnline = false
+ skip-front-matter = true
[outputs]
home = [ "HTML" ]
diff --git a/documentation/content/de/books/handbook/advanced-networking/_index.adoc b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
index d9a4550430..c9d530b68b 100644
--- a/documentation/content/de/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
@@ -2319,7 +2319,7 @@ Wenn das System bootet, werden Speicher-Dateisysteme für [.filename]#/etc# und
Der DHCP-Server muss nicht auf derselben Maschine laufen wie der TFTP- und NFS-Server, aber er muss über das Netzwerk erreichbar sein.
-DHCP ist nicht Bestandteil des FreeBSD Basissystems, kann jedoch über den Port package:net/isc-dhcp43-server[] oder als Paket nachinstalliert werden.
+DHCP ist nicht Bestandteil des FreeBSD Basissystems, kann jedoch über den Port package:net/isc-dhcp44-server[] oder als Paket nachinstalliert werden.
Einmal installiert, bearbeiten Sie die Konfigurationsdatei [.filename]#/usr/local/etc/dhcpd.conf#. Konfigurieren Sie die `next-server`, `filename` und `root-path` Einstellungen, wie in diesem Beispiel zu sehen ist:
diff --git a/documentation/content/de/books/handbook/network-servers/_index.adoc b/documentation/content/de/books/handbook/network-servers/_index.adoc
index 4b0d0f059f..3dfbb1f2bb 100644
--- a/documentation/content/de/books/handbook/network-servers/_index.adoc
+++ b/documentation/content/de/books/handbook/network-servers/_index.adoc
@@ -1517,9 +1517,9 @@ Der DHCP-Client verfügt über eine Datenbank, die alle derzeit gültigen Leases
[[network-dhcp-server]]
=== Einen DHCP-Server installieren und einrichten
-Dieser Abschnitt beschreibt die Einrichtung eines FreeBSD-Systems als DHCP-Server. Dazu wird die DHCP-Implementation von ISC (Internet Systems Consortium) verwendet. Diese Implementation und die Dokumentation können als Port oder Paket package:net/isc-dhcp43-server[] installiert werden.
+Dieser Abschnitt beschreibt die Einrichtung eines FreeBSD-Systems als DHCP-Server. Dazu wird die DHCP-Implementation von ISC (Internet Systems Consortium) verwendet. Diese Implementation und die Dokumentation können als Port oder Paket package:net/isc-dhcp44-server[] installiert werden.
-Der Port package:net/isc-dhcp43-server[] installiert eine Beispiel-Konfigurationsdatei. Kopieren Sie [.filename]#/usr/local/etc/dhcpd.conf.example# nach [.filename]#/usr/local/etc/dhcpd.conf# und nehmen Sie die Änderungen an der neuen Datei vor.
+Der Port package:net/isc-dhcp44-server[] installiert eine Beispiel-Konfigurationsdatei. Kopieren Sie [.filename]#/usr/local/etc/dhcpd.conf.example# nach [.filename]#/usr/local/etc/dhcpd.conf# und nehmen Sie die Änderungen an der neuen Datei vor.
Diese Konfigurationsdatei umfasst Deklarationen für Subnetze und Rechner, die den DHCP-Cleints zur Verfügung gestellt wird. Die folgenden Zeilen konfigurieren Folgendes:
@@ -1596,7 +1596,7 @@ Die Konfigurationsdatei des Servers muss alle Informationen enthalten, die an di
Der DHCP-Server hat eine Datenbank, die alle vergebenen Leases enthält. Diese wird als Logdatei erzeugt. man:dhcpd.leases[5] enthält eine ausführliche Beschreibung.
* [.filename]#/usr/local/sbin/dhcrelay#
+
-Dieser Daemon wird in komplexen Umgebungen verwendet, in denen ein DHCP-Server eine Anfrage eines Clients an einen DHCP-Server in einem separaten Netzwerk weiterleitet. Wenn Sie diese Funktion benötigen, müssen Sie package:net/isc-dhcp43-relay[] installieren. Weitere Informationen zu diesem Thema finden Sie in man:dhcrelay[8].
+Dieser Daemon wird in komplexen Umgebungen verwendet, in denen ein DHCP-Server eine Anfrage eines Clients an einen DHCP-Server in einem separaten Netzwerk weiterleitet. Wenn Sie diese Funktion benötigen, müssen Sie package:net/isc-dhcp44-relay[] installieren. Weitere Informationen zu diesem Thema finden Sie in man:dhcrelay[8].
[[network-dns]]
== Domain Name System (DNS)
diff --git a/documentation/content/el/books/handbook/mirrors/_index.adoc b/documentation/content/el/books/handbook/mirrors/_index.adoc
index 856abb90b1..c800a74758 100644
--- a/documentation/content/el/books/handbook/mirrors/_index.adoc
+++ b/documentation/content/el/books/handbook/mirrors/_index.adoc
@@ -470,15 +470,6 @@ In case of problems, please contact the hostmaster `<{mirrors-us-email}>` for th
* {mirrors-us-ftp14} (ftp / {mirrors-us-ftp14-http})
* {mirrors-us-ftp15} (ftp)
-[[mirrors-bittorrent]]
-== BitTorrent
-
-Μπορείτε να ανακτήσετε τα βασικά αρχεία ISO των εκδόσεων του FreeBSD, μέσω του συστήματος BitTorrent. Στην τοποθεσία http://torrents.freebsd.org:8080/[http://torrents.freebsd.org:8080] υπάρχει μια πλήρης συλλογή από αρχεία torrent που μπορείτε να κατεβάσετε.
-
-Για να χρησιμοποιήσετε τα αρχεία torrent, θα χρειαστείτε κατάλληλο λογισμικό-πελάτη, όπως αυτό που παρέχεται από το port ή πακέτο package:net-p2p/py-bittorrent[].
-
-Αφού κατεβάσετε το αρχείο ISO με το BitTorrent, μπορείτε να το γράψετε σε CD ή DVD, όπως περιγράφεται στο crossref:disks[burncd,burncd] (burncd).
-
[[anoncvs]]
== Ανώνυμο CVS
diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc
index 557630327b..216afb4458 100644
--- a/documentation/content/en/articles/committers-guide/_index.adoc
+++ b/documentation/content/en/articles/committers-guide/_index.adoc
@@ -111,7 +111,7 @@ Useful links:
Cryptographic keys conforming to the OpenPGP (__Pretty Good Privacy__) standard are used by the FreeBSD project to authenticate committers.
Messages carrying important information like public SSH keys can be signed with the OpenPGP key to prove that they are really from the committer.
-See http://www.nostarch.com/pgp_ml.htm[PGP & GPG: Email for the Practical Paranoid by Michael Lucas] and http://en.wikipedia.org/wiki/Pretty_Good_Privacy[] for more information.
+See https://nostarch.com/releases/pgp_release.pdf[PGP & GPG: Email for the Practical Paranoid by Michael Lucas] and http://en.wikipedia.org/wiki/Pretty_Good_Privacy[] for more information.
[[pgpkeys-creating]]
=== Creating a Key
@@ -625,10 +625,10 @@ You can do this by setting a few configuration variables:
[source,shell]
....
-% git config --add user.signingKey=LONG-KEY-ID
-% git config --add commit.gpgSign=true
-% git config --add tag.gpgSign=true
-% git config --add push.gpgSign=if-asked
+% git config --add user.signingKey LONG-KEY-ID
+% git config --add commit.gpgSign true
+% git config --add tag.gpgSign true
+% git config --add push.gpgSign if-asked
....
// push.gpgSign should probably be set to `yes` once we enable it, or be set with --global, so that it is enabled for all repositories.
@@ -670,6 +670,7 @@ There is also a mirror on GitHub, see extref:{handbook}/mirrors[External mirrors
The 'current' branch is 'main' .
The quarterly branches are named 'yyyyQn' for year 'yyyy' and quarter 'n'.
+[[port-commit-message-formats]]
===== Commit message formats
A hook is available in the ports repository to help you write up your commit messages in https://cgit.freebsd.org/ports/tree/.hooks/prepare-commit-msg[.hooks/prepare-commit-message].
@@ -2474,7 +2475,7 @@ Those who have been given commit rights to the FreeBSD repositories must follow
[[commit-steps]]
[.procedure]
====
-*Procedure 1. Steps for New Committers*
+*Steps for New Committers*
. Add an Author Entity
+
@@ -2645,6 +2646,50 @@ freebsd yourusername:yourpassword
....
====
+[[smtp-setup-local-exim]]
+.Using Exim
+[example]
+====
+
+To direct a local Exim instance to forward all mail from `_example_@FreeBSD.org`
+ to FreeBSD.org servers, add this to Exim [.filename]#configuration#:
+
+[.programlisting]
+....
+Routers section: (at the top of the list):
+freebsd_send:
+ driver = manualroute
+ domains = !+local_domains
+ transport = freebsd_smtp
+ route_data = ${lookup {${lc:$sender_address}} lsearch {/usr/local/etc/exim/freebsd_send}}
+
+Transport Section:
+freebsd_smtp:
+ driver = smtp
+ tls_certificate=<local certificate>
+ tls_privatekey=<local certificate private key>
+ tls_require_ciphers = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+AESGCM:EECDH:EDH+AESGCM:EDH+aRSA:HIGH:!MEDIUM:!LOW:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!SRP:!DSS
+ dkim_domain = <local DKIM domain>
+ dkim_selector = <local DKIM selector>
+ dkim_private_key= <local DKIM private key>
+ dnssec_request_domains = *
+ hosts_require_auth = smtp.freebsd.org
+
+Authenticators:
+fixed_plain:
+ driver = plaintext
+ public_name = PLAIN
+ client_send = ^example/mail^examplePassword
+....
+
+Create [.filename]#/usr/local/etc/exim/freebsd_send# with the following content:
+
+[.programlisting]
+....
+example@freebsd.org:smtp.freebsd.org::587
+....
+
+====
[[mentors]]
=== Mentors
@@ -3212,7 +3257,7 @@ You can find out more about Bugzilla at:
== Phabricator
The FreeBSD Project utilizes https://reviews.freebsd.org[Phabricator] for code review requests.
-See the https://wiki.freebsd.org/CodeReview[CodeReview] wiki page for details.
+See the https://wiki.freebsd.org/Phabricator[Phabricator wiki page] for details.
Committers with non-``FreeBSD.org`` Phabricator accounts can have the old account renamed to the ``FreeBSD.org`` account by following these steps:
@@ -3248,10 +3293,6 @@ If there is something you want merged from FreeBSD-CURRENT to FreeBSD-STABLE (wh
`{so}`::
`{so-name}` is the link:https://www.FreeBSD.org/security/[FreeBSD Security Officer] and oversees the `{security-officer}`.
-`{wollman}`::
-If you need advice on obscure network internals or are not sure of some potential change to the networking subsystem you have in mind, Garrett is someone to talk to.
-Garrett is also very knowledgeable on the various standards applicable to FreeBSD.
-
{committers-name}::
{svn-src-all}, {svn-ports-all} and {svn-doc-all} are the mailing lists that the version control system uses to send commit messages to.
_Never_ send email directly to these lists.
@@ -3576,7 +3617,7 @@ Tiers are defined for both kernels and userland ABIs. In the common case, a plat
=== Tier 1: Fully-Supported Architectures
Tier 1 platforms are the most mature FreeBSD platforms.
-They are supported by the security officer, release engineering, and port management teams.
+They are supported by the security officer, release engineering, and Ports Management Team.
Tier 1 architectures are expected to be Production Quality with respect to all aspects of the FreeBSD operating system, including installation and development environments.
The FreeBSD Project provides the following guarantees to consumers of Tier 1 platforms:
@@ -3612,7 +3653,7 @@ Collectively, developers are required to provide the following to maintain the T
=== Tier 2: Developmental and Niche Architectures
Tier 2 platforms are functional, but less mature FreeBSD platforms.
-They are not supported by the security officer, release engineering, and port management teams.
+They are not supported by the security officer, release engineering, and Ports Management Team.
Tier 2 platforms may be Tier 1 platform candidates that are still under active development.
Architectures reaching end of life may also be moved from Tier 1 status to Tier 2 status as the availability of resources to continue to maintain the system in a Production Quality state diminishes.
@@ -3640,7 +3681,7 @@ Collectively, developers are required to provide the following to maintain the T
=== Tier 3: Experimental Architectures
Tier 3 platforms have at least partial FreeBSD support.
-They are _not_ supported by the security officer, release engineering, and port management teams.
+They are _not_ supported by the security officer, release engineering, and Ports Management Team.
Tier 3 platforms are architectures in the early stages of development, for non-mainstream hardware platforms, or which are considered legacy systems unlikely to see broad future use.
Initial support for Tier 3 platforms may exist in a separate repository rather than the main source repository.
@@ -3670,13 +3711,25 @@ For a platform to be promoted to a higher tier, any missing support guarantees m
[[ports-qa-add-new]]
==== How do I add a new port?
-First, please read the section about repository copies.
+Adding a port to the tree is relatively simple. Once the port is ready to be added, as explained later <<ports-qa-add-new-extra,here>>, you need to add the port's directory entry in the category's [.filename]#Makefile#.
+In this [.filename]#Makefile#, ports are listed in alphabetical order and added to the `SUBDIR` variable, like this:
+
+[.programlisting]
+....
+ SUBDIR += newport
+....
-The easiest way to add a new port is the `addport` script located in the [.filename]#ports/Tools/scripts# directory.
-It adds a port from the directory specified, determining the category automatically from the port [.filename]#Makefile#.
-It also adds an entry to the port's category [.filename]#Makefile#.
-It was written by `{mharo}`, `{will}`, and `{garga}`.
-When sending questions about this script to the {freebsd-ports}, please also CC `{crees}`, the current maintainer.
+Once the port and its category's Makefile are ready, the new port can be committed:
+[source,shell]
+....
+% git add category/Makefile category/newport
+% git commit
+% git push
+....
+[TIP]
+====
+Don't forget to <<port-commit-message-formats,setup git hooks for the ports tree as explained here>>; a specific hook has been developed to verify the category's [.filename]#Makefile#.
+====
[[ports-qa-add-new-extra]]
==== Any other things I need to know when I add a new port?
@@ -3735,7 +3788,6 @@ When using Git, consider using man:git-grep[1], it is much faster than `grep -r`
* Remove the port's files and directory with `git rm`.
* Remove the `SUBDIR` listing of the port in the parent directory [.filename]#Makefile#.
* Add an entry to [.filename]#ports/MOVED#.
-* Search for entries in [.filename]#ports/security/vuxml/vuln.xml# and adjust them accordingly. In particular, check for previous packages with the new name which version could include the new port.
* Remove the port from [.filename]#ports/LEGAL# if it is there.
====
@@ -3751,6 +3803,7 @@ When sending questions about this script to the {freebsd-ports}, please also CC
. Perform a thorough check of the ports collection for any dependencies on the old port location/name, and update them. Running `grep` on [.filename]#INDEX# is not enough because some ports have dependencies enabled by compile-time options. A full man:git-grep[1] of the ports collection is recommended.
. Remove the `SUBDIR` entry from the old category Makefile and add a `SUBDIR` entry to the new category Makefile.
. Add an entry to [.filename]#ports/MOVED#.
+. Search for entries in xml files inside [.filename]#ports/security/vuxml# and adjust them accordingly. In particular, check for previous packages with the new name which version could include the new port.
. Move the port with `git mv`.
. Commit the changes.
====
@@ -3836,7 +3889,7 @@ To do this, you will need to:
. If you want to be really thorough, now might be a good time to run man:portlint[1].
======
+
-. Check that the ``PKGORIGIN``s are correct. The ports system uses each port's `CATEGORIES` entry to create its `PKGORIGIN`, which is used to connect installed packages to the port directory they were built from. If this entry is wrong, common port tools like man:pkg_version[1] and man:portupgrade[1] fail.
+. Check that the ``PKGORIGIN``s are correct. The ports system uses each port's `CATEGORIES` entry to create its `PKGORIGIN`, which is used to connect installed packages to the port directory they were built from. If this entry is wrong, common port tools like man:pkg-version[8] and man:portupgrade[1] fail.
+
To do this, use the [.filename]#chkorigin.sh# tool: `env PORTSDIR=/path/to/ports sh -e /path/to/ports/Tools/scripts/chkorigin.sh`. This will check every port in the ports tree, even those not connected to the build, so you can run it directly after the move operation. Hint: do not forget to look at the ``PKGORIGIN``s of any slave ports of the ports you just moved!
. On your own local system, test the proposed changes: first, comment out the SUBDIR entries in the old ports' categories' [.filename]##Makefile##s; then enable building the new category in [.filename]#ports/Makefile#. Run make checksubdirs in the affected category directories to check the SUBDIR entries. Next, in the [.filename]#ports/# directory, run make index. This can take over 40 minutes on even modern systems; however, it is a necessary step to prevent problems for other people.
@@ -3942,47 +3995,15 @@ Get your mentor to add you to the "Additional Contributors" ([.filename]#doc/sha
== Information About Google Analytics
As of December 12, 2012, Google Analytics was enabled on the FreeBSD Project website to collect anonymized usage statistics regarding usage of the site.
-The information collected is valuable to the FreeBSD Documentation Project, to identify various problems on the FreeBSD website.
-
-[[google-analytics-policy]]
-=== Google Analytics General Policy
-
-The FreeBSD Project takes visitor privacy very seriously.
-As such, the FreeBSD Project website honors the "Do Not Track" header _before_ fetching the tracking code from Google.
-For more information, please see the https://www.FreeBSD.org/privacy/[FreeBSD Privacy Policy].
-
-Google Analytics access is _not_ arbitrarily allowed - access must be requested, voted on by the `{doceng}`, and explicitly granted.
-
-Requests for Google Analytics data must include a specific purpose.
-For example, a valid reason for requesting access would be "to see the most frequently used web browsers when viewing FreeBSD web pages to ensure page rendering speeds are acceptable."
-
-Conversely, "to see what web browsers are most frequently used" (without stating __why__) would be rejected.
-
-All requests must include the timeframe for which the data would be required.
-For example, it must be explicitly stated if the requested data would be needed for a timeframe covering a span of 3 weeks, or if the request would be one-time only.
-
-Any request for Google Analytics data without a clear, reasonable reason beneficial to the FreeBSD Project will be rejected.
-
-[[google-analytics-data]]
-=== Data Available Through Google Analytics
-A few examples of the types of Google Analytics data available include:
-
-* Commonly used web browsers
-* Page load times
-* Site access by language
+[NOTE]
+====
+As of March 3, 2022, Google Analytics was removed from the FreeBSD Project.
+====
[[misc]]
== Miscellaneous Questions
-=== Are there changes that can be committed without asking the maintainer for approval?
-
-Blanket approval for most ports applies to these types of fixes:
-
-* Most infrastructure changes to a port (that is, modernizing, but not changing the functionality). For example, the blanket covers converting to new `USES` macros, enabling verbose builds, and switching to new ports system syntaxes.
-* Trivial and _tested_ build and runtime fixes.
-* Documentations or metadata changes to ports, like [.filename]#pkg-descr# or `COMMENT`.
-
=== How do I access people.FreeBSD.org to put up personal or project information?
`people.FreeBSD.org` is the same as `freefall.FreeBSD.org`.
diff --git a/documentation/content/en/articles/contributing/_index.adoc b/documentation/content/en/articles/contributing/_index.adoc
index 63ebc42b39..cd889a2361 100644
--- a/documentation/content/en/articles/contributing/_index.adoc
+++ b/documentation/content/en/articles/contributing/_index.adoc
@@ -265,12 +265,10 @@ There are a large number of unmaintained ports.
It is a good idea to start with adopting a port that you use regularly.
Unmaintained ports have their `MAINTAINER` set to `ports@FreeBSD.org`.
-A list of unmaintained ports and their current errors and problem reports can be seen at the http://portsmon.FreeBSD.org/portsconcordanceformaintainer.py?maintainer=ports%40FreeBSD.org[FreeBSD Ports Monitoring System].
+Many unmaintained ports can have pending updates, this can be seen at the https://portscout.freebsd.org/ports@freebsd.org.html[FreeBSD Ports distfile scanner].
On https://portsfallout.com/fallout?port=&maintainer=ports%40FreeBSD.org[PortsFallout] can be seen a list of unmaintained ports with errors.
-Many unmaintained ports can have pending updates, this can be seen at the https://portscout.freebsd.org/ports@freebsd.org.html[FreeBSD Ports distfile scanner].
-
Some ports affect a large number of others due to dependencies and slave port relationships.
Generally, we want people to have some experience before they maintain such ports.
@@ -278,11 +276,6 @@ You can find out whether or not a port has dependencies or slave ports by lookin
(The name of the file varies by release of FreeBSD; for instance, [.filename]#INDEX-8#.) Some ports have conditional dependencies that are not included in a default [.filename]#INDEX# build.
We expect you to be able to recognize such ports by looking through other ports' [.filename]#Makefile#'s.
-[NOTE]
-======
-The FreeBSD Ports Monitoring System (portsmon) is currently not working due to latest Python updates.
-======
-
==== How to adopt the port
First make sure you understand your <<maintain-port>>.
@@ -525,9 +518,6 @@ There are some really good places to find a port that needs some attention.
You can use the https://bugs.freebsd.org/search[web interface] to the Problem Report database to search through and view unresolved PRs.
The majority of ports PRs are updates, but with a little searching and skimming over synopses you should be able to find something interesting to work on (the `sw-bug` class is a good place to start).
-The other place is the http://portsmon.FreeBSD.org/[FreeBSD Ports Monitoring System].
-In particular look for unmaintained ports with build errors and ports that are marked `BROKEN`.
-
https://portsfallout.com/[PortsFallout] shows port issues gathered from the FreeBSD package building.
It is OK to send changes for a maintained port as well, but remember to ask the maintainer in case they are already working on the problem.
@@ -536,11 +526,6 @@ Once you have found a bug or problem, collect information, investigate and fix!
Otherwise create a new PR.
Your changes will be reviewed and, if everything checks out, committed.
-[NOTE]
-======
-The FreeBSD Ports Monitoring System (portsmon) is currently not working due to latest Python updates.
-======
-
[[mortal-coil]]
=== When to call it quits
@@ -563,10 +548,6 @@ In 2005 more than eleven thousand ports PRs were submitted! Following this artic
The https://bugs.freebsd.org/bugzilla/query.cgi[Problem Report database].
-The http://portsmon.FreeBSD.org/[FreeBSD Ports Monitoring System (portsmon)] can show you cross-referenced information about ports such as build errors and problem reports.
-If you are a maintainer you can use it to check on the build status of your ports.
-As a contributor you can use it to find broken and unmaintained ports that need to be fixed.
-
The http://portscout.FreeBSD.org[FreeBSD Ports distfile scanner (portscout)] can show you ports for which the distfiles are not fetchable.
You can check on your own ports or use it to find ports that need their `MASTER_SITES` updated.
diff --git a/documentation/content/en/articles/contributors/_index.adoc b/documentation/content/en/articles/contributors/_index.adoc
index fcedd93ebd..55e1887b8d 100644
--- a/documentation/content/en/articles/contributors/_index.adoc
+++ b/documentation/content/en/articles/contributors/_index.adoc
@@ -61,6 +61,7 @@ endif::[]
Abstract
This article lists individuals and organizations who have made a contribution to FreeBSD.
+To see the current list of FreeBSD Committers you can take a look at the following <<staff-committers, list>>.
'''
@@ -137,8 +138,8 @@ The following individuals and businesses have generously contributed hardware fo
[[staff-committers]]
== The FreeBSD Developers
-These are the people who have commit privileges and do the engineering work on the FreeBSD source tree.
-All core team members are also developers.
+This list, which includes all members of the Core Team, names everyone who has commit privileges for one or more of the three source trees (doc, ports and src).
+To see the current Core Team members you can take a look at the link:https://www.freebsd.org/administration/#t-core[administration page].
(in alphabetical order by last name):
diff --git a/documentation/content/en/articles/freebsd-releng/_index.adoc b/documentation/content/en/articles/freebsd-releng/_index.adoc
index 86d34f3ba1..02452258df 100644
--- a/documentation/content/en/articles/freebsd-releng/_index.adoc
+++ b/documentation/content/en/articles/freebsd-releng/_index.adoc
@@ -561,6 +561,9 @@ The order of commits and what to change are:
|[.filename]#releng/12.0/sys/sys/param.h#
|Update `__FreeBSD_version`
+|[.filename]#releng/12.0/sys/conf/kern.opts.mk
+|Move `REPRODUCIBLE_BUILD` from `__DEFAULT_NO_OPTIONS` to `__DEFAULT_YES_OPTIONS`
+
|[.filename]#releng/12.0/etc/pkg/FreeBSD.conf#
|Replace `latest` with `quarterly` as the default package repository location
@@ -744,7 +747,7 @@ In preparation for the release build, several files need to be updated:
|[.filename]#UPDATING#
|Add the anticipated announcement date
-|[.filename]#lib/csu/common/crtbrand.c#
+|[.filename]#lib/csu/common/crtbrand.S#
|Replace `__FreeBSD_version` with the value in [.filename]#sys/sys/param.h#
|===
diff --git a/documentation/content/en/articles/freebsd-src-lsp/_index.adoc b/documentation/content/en/articles/freebsd-src-lsp/_index.adoc
index 87286645a7..8b6647833f 100644
--- a/documentation/content/en/articles/freebsd-src-lsp/_index.adoc
+++ b/documentation/content/en/articles/freebsd-src-lsp/_index.adoc
@@ -255,7 +255,7 @@ In the top-level directory of the FreeBSD src tree, to generate compilation data
[source,shell]
....
-# bear --append make buildworld buildkernel -j`sysctl -n hw.ncpu`
+# bear --append -- make buildworld buildkernel -j`sysctl -n hw.ncpu`
....
The `--append` flag tells `bear` to read an existing compilation database if it is present, and append the results to the database.
diff --git a/documentation/content/en/articles/freebsd-update-server/_index.adoc b/documentation/content/en/articles/freebsd-update-server/_index.adoc
index caaf17a3d7..dda1d906b3 100644
--- a/documentation/content/en/articles/freebsd-update-server/_index.adoc
+++ b/documentation/content/en/articles/freebsd-update-server/_index.adoc
@@ -44,7 +44,7 @@ endif::[]
Abstract
This article describes building an internal FreeBSD Update Server.
-The https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/[freebsd-update-server] is written by `{cperciva}`, Security Officer Emeritus of FreeBSD.
+The https://github.com/freebsd/freebsd-update-build/[freebsd-update-server] is written by `{cperciva}`, Security Officer Emeritus of FreeBSD.
For users that think it is convenient to update their systems against an official update server, building their own FreeBSD Update Server may help to extend its functionality by supporting manually-tweaked FreeBSD releases or by providing a local mirror that will allow faster updates for a number of machines.
'''
@@ -84,11 +84,11 @@ At a minimum, updates require building on a FreeBSD release greater than or equa
[[Configuration]]
== Configuration: Installation & Setup
-Download the https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/[freebsd-update-server] software by installing package:devel/subversion[] and package:security/ca_root_nss[], and execute:
+Download the https://github.com/freebsd/freebsd-update-build/[freebsd-update-server] software by installing package:devel/git[] and package:security/ca_root_nss[], and execute:
[source,shell]
....
-% svn co https://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server
+% git clone https://github.com/freebsd/freebsd-update-build.git freebsd-update-server
....
Update [.filename]#scripts/build.conf# appropriately.
@@ -271,7 +271,7 @@ A more detailed explanation may be found in [.filename]#scripts/build.subr#.
[WARNING]
====
During this second build cycle, the network time protocol daemon, man:ntpd[8], is turned off.
-Per `{cperciva}`, Security Officer Emeritus of FreeBSD, "the https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/[freebsd-update-server] build code needs to identify timestamps which are stored in files so that they can be ignored when comparing builds to determine which files need to be updated.
+Per `{cperciva}`, Security Officer Emeritus of FreeBSD, "the https://github.com/freebsd/freebsd-update-build/[freebsd-update-server] build code needs to identify timestamps which are stored in files so that they can be ignored when comparing builds to determine which files need to be updated.
This timestamp-finding works by doing two builds 400 days apart and comparing the results."
====
diff --git a/documentation/content/en/articles/hubs/_index.adoc b/documentation/content/en/articles/hubs/_index.adoc
index 1e2c9da25a..9c5bf2506e 100644
--- a/documentation/content/en/articles/hubs/_index.adoc
+++ b/documentation/content/en/articles/hubs/_index.adoc
@@ -214,14 +214,33 @@ If you sync the whole module (unlike subdirectories), be aware that the module-d
[[mirror-www]]
=== Mirroring the WWW Pages
-The FreeBSD website should only be mirrored via rsync.
+[WARNING]
+====
+Since doc migration to Hugo/Asciidoctor on 2021-01-25, mirroring the website with rsync no longer works.
+====
+
+There are ongoing studies to implement a website mirror with the extref:{handbook}mirrors/[official infrastructure].
+
+For the former website mirrors, a way to achieve mirroring the website today is building the website locally with the corresponding address it will be hosted.
+
+[source,shell]
+....
+% cd website && env HUGO_baseURL="https://www.XX.freebsd.org/" make
+....
-A command line to mirror the FreeBSD web site might look like:
+Check for more details about the build tools on extref:{fdp-primer}overview/[FreeBSD Documentation Project Primer for New Contributors, overview-quick-start] book.
+////
[source,shell]
....
% rsync -vaHz --delete rsync://bit0.us-west.freebsd.org/FreeBSD-www-data/ /usr/local/www/
....
+////
+
+[NOTE]
+====
+Notice the website was split into www.FreeBSD.org and docs.FreeBSD.org, and there are links between them; plus, at this moment, `HUGO_baseURL` variable won't cover all links, this way, mirroring the website is discouraged.
+====
[[mirror-pkgs]]
=== Mirroring Packages
diff --git a/documentation/content/en/articles/ldap-auth/_index.adoc b/documentation/content/en/articles/ldap-auth/_index.adoc
index 66a05a8e4f..3d1b5d718b 100644
--- a/documentation/content/en/articles/ldap-auth/_index.adoc
+++ b/documentation/content/en/articles/ldap-auth/_index.adoc
@@ -272,7 +272,7 @@ In either case, the relevant schemas need to be loaded in [.filename]#slapd.conf
For this example we will use the `person` object class.
If you are using `inetOrgPerson`, the steps are basically identical, except that the `sn` attribute is required.
-To add a user `testuser`, the ldif would be:
+To add a test-user named `tuser`, the ldif would be:
[.programlisting]
....
diff --git a/documentation/content/en/articles/pam/_index.adoc b/documentation/content/en/articles/pam/_index.adoc
index 8aa56bb4b2..011ee465c9 100644
--- a/documentation/content/en/articles/pam/_index.adoc
+++ b/documentation/content/en/articles/pam/_index.adoc
@@ -604,7 +604,7 @@ It is most useful for non-networked services such as man:su[1], where the identi
The man:pam_ssh[8] module provides both authentication and session services.
The authentication service allows users who have passphrase-protected SSH secret keys in their [.filename]#~/.ssh# directory to authenticate themselves by typing their passphrase.
The session service starts man:ssh-agent[1] and preloads it with the keys that were decrypted in the authentication phase.
-This feature is particularly useful for local logins, whether in X (using man:xdm[1] or another PAM-aware X login manager) or at the console.
+This feature is particularly useful for local logins, whether in X (using man:xdm[8] or another PAM-aware X login manager) or at the console.
[[pam-modules-tacplus]]
=== man:pam_tacplus[8]
diff --git a/documentation/content/en/articles/pgpkeys/_index.adoc b/documentation/content/en/articles/pgpkeys/_index.adoc
index 3d651721da..4d93eb0f22 100644
--- a/documentation/content/en/articles/pgpkeys/_index.adoc
+++ b/documentation/content/en/articles/pgpkeys/_index.adoc
@@ -81,33 +81,33 @@ include::{include-path}doceng-secretary.key[]
=== `{bapt}`
include::{include-path}bapt.key[]
-=== `{emaste}`
-include::{include-path}emaste.key[]
-
-=== `{gnn}`
-include::{include-path}gnn.key[]
+=== `{bcr}`
+include::{include-path}bcr.key[]
-=== `{hrs}`
-include::{include-path}hrs.key[]
+=== `{grog}`
+include::{include-path}grog.key[]
-=== `{imp}`
-include::{include-path}imp.key[]
+=== `{jhb}`
+include::{include-path}jhb.key[]
-=== `{kevans}`
-include::{include-path}kevans.key[]
+=== `{lwhsu}`
+include::{include-path}lwhsu.key[]
-=== `{markj}`
-include::{include-path}markj.key[]
+=== `{manu}`
+include::{include-path}manu.key[]
-=== `{scottl}`
-include::{include-path}scottl.key[]
+=== `{tcberner}`
+include::{include-path}tcberner.key[]
-=== `{seanc}`
-include::{include-path}seanc.key[]
+=== `{0mp}`
+include::{include-path}0mp.key[]
[[pgpkeys-developers]]
== Developers
+=== `{jgh}`
+include::{include-path}jgh.key[]
+
=== `{ariff}`
include::{include-path}ariff.key[]
@@ -117,9 +117,6 @@ include::{include-path}tabthorpe.key[]
=== `{eadler}`
include::{include-path}eadler.key[]
-=== `{mahrens}`
-include::{include-path}mahrens.key[]
-
=== `{shaun}`
include::{include-path}shaun.key[]
@@ -156,9 +153,6 @@ include::{include-path}syuu.key[]
=== `{asami}`
include::{include-path}asami.key[]
-=== `{gavin}`
-include::{include-path}gavin.key[]
-
=== `{jsa}`
include::{include-path}jsa.key[]
@@ -168,9 +162,6 @@ include::{include-path}jadawin.key[]
=== `{jwb}`
include::{include-path}jwb.key[]
-=== `{badger}`
-include::{include-path}badger.key[]
-
=== `{dbaio}`
include::{include-path}dbaio.key[]
@@ -192,9 +183,6 @@ include::{include-path}barner.key[]
=== `{lbartoletti}`
include::{include-path}lbartoletti.key[]
-=== `{jbeich}`
-include::{include-path}jbeich.key[]
-
=== `{art}`
include::{include-path}art.key[]
@@ -213,21 +201,12 @@ include::{include-path}tcberner.key[]
=== `{tdb}`
include::{include-path}tdb.key[]
-=== `{gblach}`
-include::{include-path}gblach.key[]
-
=== `{mbr}`
include::{include-path}mbr.key[]
-=== `{wblock}`
-include::{include-path}wblock.key[]
-
=== `{bvs}`
include::{include-path}bvs.key[]
-=== `{zbb}`
-include::{include-path}zbb.key[]
-
=== `{novel}`
include::{include-path}novel.key[]
@@ -240,15 +219,9 @@ include::{include-path}kbowling.key[]
=== `{alexbl}`
include::{include-path}alexbl.key[]
-=== `{sbz}`
-include::{include-path}sbz.key[]
-
=== `{ebrandi}`
include::{include-path}ebrandi.key[]
-=== `{dab}`
-include::{include-path}dab.key[]
-
=== `{harti}`
include::{include-path}harti.key[]
@@ -273,21 +246,9 @@ include::{include-path}brueffer.key[]
=== `{markus}`
include::{include-path}markus.key[]
-=== `{sbruno}`
-include::{include-path}sbruno.key[]
-
=== `{br}`
include::{include-path}br.key[]
-=== `{oleg}`
-include::{include-path}oleg.key[]
-
-=== `{bushman}`
-include::{include-path}bushman.key[]
-
-=== `{adrian}`
-include::{include-path}adrian.key[]
-
=== `{jch}`
include::{include-path}jch.key[]
@@ -327,9 +288,6 @@ include::{include-path}ache.key[]
=== `{melifaro}`
include::{include-path}melifaro.key[]
-=== `{seanc}`
-include::{include-path}seanc.key[]
-
=== `{cjh}`
include::{include-path}cjh.key[]
@@ -357,33 +315,21 @@ include::{include-path}lcook.key[]
=== `{ngie}`
include::{include-path}ngie.key[]
-=== `{tijl}`
-include::{include-path}tijl.key[]
-
=== `{rakuco}`
include::{include-path}rakuco.key[]
-=== `{dch}`
-include::{include-path}dch.key[]
-
=== `{alc}`
include::{include-path}alc.key[]
=== `{olivier}`
include::{include-path}olivier.key[]
-=== `{jeb}`
-include::{include-path}jeb.key[]
-
=== `{bcran}`
include::{include-path}bcran.key[]
=== `{culot}`
include::{include-path}culot.key[]
-=== `{aaron}`
-include::{include-path}aaron.key[]
-
=== `{alfredo}`
include::{include-path}alfredo.key[]
@@ -393,15 +339,9 @@ include::{include-path}bapt.key[]
=== `{ceri}`
include::{include-path}ceri.key[]
-=== `{brd}`
-include::{include-path}brd.key[]
-
=== `{edavis}`
include::{include-path}edavis.key[]
-=== `{pjd}`
-include::{include-path}pjd.key[]
-
=== `{alexey}`
include::{include-path}alexey.key[]
@@ -414,9 +354,6 @@ include::{include-path}carl.key[]
=== `{carlavilla}`
include::{include-path}carlavilla.key[]
-=== `{jmd}`
-include::{include-path}jmd.key[]
-
=== `{vd}`
include::{include-path}vd.key[]
@@ -435,6 +372,9 @@ include::{include-path}bdrewery.key[]
=== `{gad}`
include::{include-path}gad.key[]
+=== `{kd}`
+include::{include-path}kd.key[]
+
=== `{olivierd}`
include::{include-path}olivierd.key[]
@@ -453,36 +393,12 @@ include::{include-path}peadar.key[]
=== `{deischen}`
include::{include-path}deischen.key[]
-=== `{josef}`
-include::{include-path}josef.key[]
-
=== `{diizzy}`
include::{include-path}diizzy.key[]
-=== `{lme}`
-include::{include-path}lme.key[]
-
=== `{ue}`
include::{include-path}ue.key[]
-=== `{ru}`
-include::{include-path}ru.key[]
-
-=== `{le}`
-include::{include-path}le.key[]
-
-=== `{se}`
-include::{include-path}se.key[]
-
-=== `{kevans}`
-include::{include-path}kevans.key[]
-
-=== `{bf}`
-include::{include-path}bf.key[]
-
-=== `{sef}`
-include::{include-path}sef.key[]
-
=== `{madpilot}`
include::{include-path}madpilot.key[]
@@ -492,9 +408,6 @@ include::{include-path}rafan.key[]
=== `{kami}`
include::{include-path}kami.key[]
-=== `{stefanf}`
-include::{include-path}stefanf.key[]
-
=== `{farrokhi}`
include::{include-path}farrokhi.key[]
@@ -510,12 +423,6 @@ include::{include-path}feld.key[]
=== `{green}`
include::{include-path}green.key[]
-=== `{lioux}`
-include::{include-path}lioux.key[]
-
-=== `{mdf}`
-include::{include-path}mdf.key[]
-
=== `{fanf}`
include::{include-path}fanf.key[]
@@ -534,24 +441,18 @@ include::{include-path}landonf.key[]
=== `{billf}`
include::{include-path}billf.key[]
-=== `{sg}`
-include::{include-path}sg.key[]
+=== `{grembo}`
+include::{include-path}grembo.key[]
=== `{sgalabov}`
include::{include-path}sgalabov.key[]
-=== `{ultima}`
-include::{include-path}ultima.key[]
-
=== `{avg}`
include::{include-path}avg.key[]
=== `{beat}`
include::{include-path}beat.key[]
-=== `{danger}`
-include::{include-path}danger.key[]
-
=== `{sjg}`
include::{include-path}sjg.key[]
@@ -573,18 +474,12 @@ include::{include-path}pgollucci.key[]
=== `{trociny}`
include::{include-path}trociny.key[]
-=== `{danilo}`
-include::{include-path}danilo.key[]
-
=== `{dmgk}`
include::{include-path}dmgk.key[]
=== `{daichi}`
include::{include-path}daichi.key[]
-=== `{mnag}`
-include::{include-path}mnag.key[]
-
=== `{grehan}`
include::{include-path}grehan.key[]
@@ -594,18 +489,12 @@ include::{include-path}jamie.key[]
=== `{adridg}`
include::{include-path}adridg.key[]
-=== `{edwin}`
-include::{include-path}edwin.key[]
-
=== `{wg}`
include::{include-path}wg.key[]
=== `{bar}`
include::{include-path}bar.key[]
-=== `{anish}`
-include::{include-path}anish.key[]
-
=== `{jmg}`
include::{include-path}jmg.key[]
@@ -615,9 +504,6 @@ include::{include-path}mjg.key[]
=== `{jhale}`
include::{include-path}jhale.key[]
-=== `{jah}`
-include::{include-path}jah.key[]
-
=== `{dannyboy}`
include::{include-path}dannyboy.key[]
@@ -648,12 +534,6 @@ include::{include-path}mheinen.key[]
=== `{niels}`
include::{include-path}niels.key[]
-=== `{jh}`
-include::{include-path}jh.key[]
-
-=== `{jgh}`
-include::{include-path}jgh.key[]
-
=== `{ghelmer}`
include::{include-path}ghelmer.key[]
@@ -684,9 +564,6 @@ include::{include-path}mhorne.key[]
=== `{bhughes}`
include::{include-path}bhughes.key[]
-=== `{mich}`
-include::{include-path}mich.key[]
-
=== `{sunpoet}`
include::{include-path}sunpoet.key[]
@@ -702,21 +579,12 @@ include::{include-path}whu.key[]
=== `{chinsan}`
include::{include-path}chinsan.key[]
-=== `{shurd}`
-include::{include-path}shurd.key[]
-
-=== `{kibab}`
-include::{include-path}kibab.key[]
-
=== `{davide}`
include::{include-path}davide.key[]
=== `{jkh}`
include::{include-path}jkh.key[]
-=== `{sevan}`
-include::{include-path}sevan.key[]
-
=== `{versus}`
include::{include-path}versus.key[]
@@ -741,24 +609,12 @@ include::{include-path}markj.key[]
=== `{trevor}`
include::{include-path}trevor.key[]
-=== `{thj}`
-include::{include-path}thj.key[]
-
-=== `{mjoras}`
-include::{include-path}mjoras.key[]
-
=== `{erj}`
include::{include-path}erj.key[]
=== `{allanjude}`
include::{include-path}allanjude.key[]
-=== `{tj}`
-include::{include-path}tj.key[]
-
-=== `{kan}`
-include::{include-path}kan.key[]
-
=== `{bjk}`
include::{include-path}bjk.key[]
@@ -777,15 +633,9 @@ include::{include-path}karels.key[]
=== `{kato}`
include::{include-path}kato.key[]
-=== `{joe}`
-include::{include-path}joe.key[]
-
=== `{vkashyap}`
include::{include-path}vkashyap.key[]
-=== `{pkelsey}`
-include::{include-path}pkelsey.key[]
-
=== `{pkubaj}`
include::{include-path}pkubaj.key[]
@@ -825,9 +675,6 @@ include::{include-path}jkois.key[]
=== `{sergei}`
include::{include-path}sergei.key[]
-=== `{wulf}`
-include::{include-path}wulf.key[]
-
=== `{maxim}`
include::{include-path}maxim.key[]
@@ -846,30 +693,18 @@ include::{include-path}wkoszek.key[]
=== `{ak}`
include::{include-path}ak.key[]
-=== `{skra}`
-include::{include-path}skra.key[]
-
-=== `{skreuzer}`
-include::{include-path}skreuzer.key[]
-
=== `{gabor}`
include::{include-path}gabor.key[]
=== `{anchie}`
include::{include-path}anchie.key[]
-=== `{rik}`
-include::{include-path}rik.key[]
-
=== `{rushani}`
include::{include-path}rushani.key[]
=== `{kuriyama}`
include::{include-path}kuriyama.key[]
-=== `{gleb}`
-include::{include-path}gleb.key[]
-
=== `{rene}`
include::{include-path}rene.key[]
@@ -882,21 +717,12 @@ include::{include-path}clement.key[]
=== `{mlaier}`
include::{include-path}mlaier.key[]
-=== `{dvl}`
-include::{include-path}dvl.key[]
-
-=== `{erwin}`
-include::{include-path}erwin.key[]
-
=== `{martymac}`
include::{include-path}martymac.key[]
=== `{glarkin}`
include::{include-path}glarkin.key[]
-=== `{laszlof}`
-include::{include-path}laszlof.key[]
-
=== `{dru}`
include::{include-path}dru.key[]
@@ -942,18 +768,12 @@ include::{include-path}achim.key[]
=== `{cel}`
include::{include-path}cel.key[]
-=== `{truckman}`
-include::{include-path}truckman.key[]
-
=== `{glewis}`
include::{include-path}glewis.key[]
=== `{vishwin}`
include::{include-path}vishwin.key[]
-=== `{qingli}`
-include::{include-path}qingli.key[]
-
=== `{delphij}`
include::{include-path}delphij.key[]
@@ -966,18 +786,6 @@ include::{include-path}ijliao.key[]
=== `{rlibby}`
include::{include-path}rlibby.key[]
-=== `{lidl}`
-include::{include-path}lidl.key[]
-
-=== `{lifanov}`
-include::{include-path}lifanov.key[]
-
-=== `{lulf}`
-include::{include-path}lulf.key[]
-
-=== `{clive}`
-include::{include-path}clive.key[]
-
=== `{pclin}`
include::{include-path}pclin.key[]
@@ -1005,27 +813,12 @@ include::{include-path}zml.key[]
=== `{nox}`
include::{include-path}nox.key[]
-=== `{remko}`
-include::{include-path}remko.key[]
-
=== `{avl}`
include::{include-path}avl.key[]
-=== `{issyl0}`
-include::{include-path}issyl0.key[]
-
=== `{scottl}`
include::{include-path}scottl.key[]
-=== `{jtl}`
-include::{include-path}jtl.key[]
-
-=== `{luporl}`
-include::{include-path}luporl.key[]
-
-=== `{wma}`
-include::{include-path}wma.key[]
-
=== `{rmacklem}`
include::{include-path}rmacklem.key[]
@@ -1044,18 +837,9 @@ include::{include-path}mtm.key[]
=== `{dwmalone}`
include::{include-path}dwmalone.key[]
-=== `{amdmi3}`
-include::{include-path}amdmi3.key[]
-
=== `{marino}`
include::{include-path}marino.key[]
-=== `{kwm}`
-include::{include-path}kwm.key[]
-
-=== `{emaste}`
-include::{include-path}emaste.key[]
-
=== `{cherry}`
include::{include-path}cherry.key[]
@@ -1068,24 +852,12 @@ include::{include-path}mm.key[]
=== `{sem}`
include::{include-path}sem.key[]
-=== `{slm}`
-include::{include-path}slm.key[]
-
-=== `{mckay}`
-include::{include-path}mckay.key[]
-
=== `{mckusick}`
include::{include-path}mckusick.key[]
=== `{tmclaugh}`
include::{include-path}tmclaugh.key[]
-=== `{jmcneill}`
-include::{include-path}jmcneill.key[]
-
-=== `{xmj}`
-include::{include-path}xmj.key[]
-
=== `{jmelo}`
include::{include-path}jmelo.key[]
@@ -1122,9 +894,6 @@ include::{include-path}jrm.key[]
=== `{freqlabs}`
include::{include-path}freqlabs.key[]
-=== `{mmokhi}`
-include::{include-path}mmokhi.key[]
-
=== `{mmoll}`
include::{include-path}mmoll.key[]
@@ -1149,9 +918,6 @@ include::{include-path}marck.key[]
=== `{mav}`
include::{include-path}mav.key[]
-=== `{lippe}`
-include::{include-path}lippe.key[]
-
=== `{rich}`
include::{include-path}rich.key[]
@@ -1161,9 +927,6 @@ include::{include-path}knu.key[]
=== `{tmm}`
include::{include-path}tmm.key[]
-=== `{jsm}`
-include::{include-path}jsm.key[]
-
=== `{max}`
include::{include-path}max.key[]
@@ -1173,21 +936,9 @@ include::{include-path}maho.key[]
=== `{yoichi}`
include::{include-path}yoichi.key[]
-=== `{trasz}`
-include::{include-path}trasz.key[]
-
-=== `{neel}`
-include::{include-path}neel.key[]
-
-=== `{dbn}`
-include::{include-path}dbn.key[]
-
=== `{bland}`
include::{include-path}bland.key[]
-=== `{joneum}`
-include::{include-path}joneum.key[]
-
=== `{gnn}`
include::{include-path}gnn.key[]
@@ -1212,27 +963,18 @@ include::{include-path}obrien.key[]
=== `{olgeni}`
include::{include-path}olgeni.key[]
-=== `{phil}`
-include::{include-path}phil.key[]
-
=== `{philip}`
include::{include-path}philip.key[]
=== `{jpaetzel}`
include::{include-path}jpaetzel.key[]
-=== `{pgj}`
-include::{include-path}pgj.key[]
-
=== `{hiren}`
include::{include-path}hiren.key[]
=== `{hmp}`
include::{include-path}hmp.key[]
-=== `{yuripv}`
-include::{include-path}yuripv.key[]
-
=== `{fluffy}`
include::{include-path}fluffy.key[]
@@ -1248,11 +990,8 @@ include::{include-path}royger.key[]
=== `{rpaulo}`
include::{include-path}rpaulo.key[]
-=== `{misha}`
-include::{include-path}misha.key[]
-
-=== `{dumbbell}`
-include::{include-path}dumbbell.key[]
+=== `{rpokala}`
+include::{include-path}rpokala.key[]
=== `{mp}`
include::{include-path}mp.key[]
@@ -1278,12 +1017,6 @@ include::{include-path}jacula.key[]
=== `{0mp}`
include::{include-path}0mp.key[]
-=== `{pizzamig}`
-include::{include-path}pizzamig.key[]
-
-=== `{rpokala}`
-include::{include-path}rpokala.key[]
-
=== `{jdp}`
include::{include-path}jdp.key[]
@@ -1311,9 +1044,6 @@ include::{include-path}thomas.key[]
=== `{hq}`
include::{include-path}hq.key[]
-=== `{dfr}`
-include::{include-path}dfr.key[]
-
=== `{bofh}`
include::{include-path}bofh.key[]
@@ -1335,24 +1065,15 @@ include::{include-path}mr.key[]
=== `{bcr}`
include::{include-path}bcr.key[]
-=== `{rezny}`
-include::{include-path}rezny.key[]
-
=== `{trhodes}`
include::{include-path}trhodes.key[]
=== `{benno}`
include::{include-path}benno.key[]
-=== `{arichardson}`
-include::{include-path}arichardson.key[]
-
=== `{beech}`
include::{include-path}beech.key[]
-=== `{matteo}`
-include::{include-path}matteo.key[]
-
=== `{roberto}`
include::{include-path}roberto.key[]
@@ -1377,9 +1098,6 @@ include::{include-path}rea.key[]
=== `{ray}`
include::{include-path}ray.key[]
-=== `{arybchik}`
-include::{include-path}arybchik.key[]
-
=== `{niklas}`
include::{include-path}niklas.key[]
@@ -1392,18 +1110,12 @@ include::{include-path}bsam.key[]
=== `{marks}`
include::{include-path}marks.key[]
-=== `{alonso}`
-include::{include-path}alonso.key[]
-
=== `{bschmidt}`
include::{include-path}bschmidt.key[]
=== `{wosch}`
include::{include-path}wosch.key[]
-=== `{ed}`
-include::{include-path}ed.key[]
-
=== `{cy}`
include::{include-path}cy.key[]
@@ -1413,36 +1125,21 @@ include::{include-path}das.key[]
=== `{scheidell}`
include::{include-path}scheidell.key[]
-=== `{schweikh}`
-include::{include-path}schweikh.key[]
-
=== `{matthew}`
include::{include-path}matthew.key[]
=== `{tmseck}`
include::{include-path}tmseck.key[]
-=== `{stas}`
-include::{include-path}stas.key[]
-
-=== `{johalun}`
-include::{include-path}johalun.key[]
-
=== `{johans}`
include::{include-path}johans.key[]
-=== `{lev}`
-include::{include-path}lev.key[]
-
=== `{bakul}`
include::{include-path}bakul.key[]
=== `{gshapiro}`
include::{include-path}gshapiro.key[]
-=== `{arun}`
-include::{include-path}arun.key[]
-
=== `{wxs}`
include::{include-path}wxs.key[]
@@ -1458,6 +1155,9 @@ include::{include-path}vanilla.key[]
=== `{ashish}`
include::{include-path}ashish.key[]
+=== `{asiciliano}`
+include::{include-path}asiciliano.key[]
+
=== `{chs}`
include::{include-path}chs.key[]
@@ -1509,18 +1209,12 @@ include::{include-path}nsouch.key[]
=== `{ssouhlal}`
include::{include-path}ssouhlal.key[]
-=== `{tsoome}`
-include::{include-path}tsoome.key[]
-
=== `{loos}`
include::{include-path}loos.key[]
=== `{brnrd}`
include::{include-path}brnrd.key[]
-=== `{uqs}`
-include::{include-path}uqs.key[]
-
=== `{rink}`
include::{include-path}rink.key[]
@@ -1536,18 +1230,12 @@ include::{include-path}zi.key[]
=== `{lstewart}`
include::{include-path}lstewart.key[]
-=== `{rrs}`
-include::{include-path}rrs.key[]
-
=== `{murray}`
include::{include-path}murray.key[]
=== `{vs}`
include::{include-path}vs.key[]
-=== `{rstone}`
-include::{include-path}rstone.key[]
-
=== `{xride}`
include::{include-path}xride.key[]
@@ -1569,9 +1257,6 @@ include::{include-path}metal.key[]
=== `{ryusuke}`
include::{include-path}ryusuke.key[]
-=== `{garys}`
-include::{include-path}garys.key[]
-
=== `{nyan}`
include::{include-path}nyan.key[]
@@ -1590,9 +1275,6 @@ include::{include-path}eduardo.key[]
=== `{sylvio}`
include::{include-path}sylvio.key[]
-=== `{dteske}`
-include::{include-path}dteske.key[]
-
=== `{itetcu}`
include::{include-path}itetcu.key[]
@@ -1605,12 +1287,6 @@ include::{include-path}gordon.key[]
=== `{lth}`
include::{include-path}lth.key[]
-=== `{jase}`
-include::{include-path}jase.key[]
-
-=== `{lx}`
-include::{include-path}lx.key[]
-
=== `{fabient}`
include::{include-path}fabient.key[]
@@ -1632,18 +1308,12 @@ include::{include-path}ganbold.key[]
=== `{tuexen}`
include::{include-path}tuexen.key[]
-=== `{andrew}`
-include::{include-path}andrew.key[]
-
=== `{gonzo}`
include::{include-path}gonzo.key[]
=== `{ume}`
include::{include-path}ume.key[]
-=== `{junovitch}`
-include::{include-path}junovitch.key[]
-
=== `{ups}`
include::{include-path}ups.key[]
@@ -1653,15 +1323,9 @@ include::{include-path}fsu.key[]
=== `{mikael}`
include::{include-path}mikael.key[]
-=== `{ivadasz}`
-include::{include-path}ivadasz.key[]
-
=== `{manu}`
include::{include-path}manu.key[]
-=== `{vangyzen}`
-include::{include-path}vangyzen.key[]
-
=== `{ram}`
include::{include-path}ram.key[]
@@ -1680,9 +1344,6 @@ include::{include-path}nivit.key[]
=== `{ivoras}`
include::{include-path}ivoras.key[]
-=== `{avos}`
-include::{include-path}avos.key[]
-
=== `{stefan}`
include::{include-path}stefan.key[]
@@ -1707,42 +1368,24 @@ include::{include-path}miwi.key[]
=== `{nate}`
include::{include-path}nate.key[]
-=== `{swills}`
-include::{include-path}swills.key[]
-
=== `{twinterg}`
include::{include-path}twinterg.key[]
=== `{def}`
include::{include-path}def.key[]
-=== `{mw}`
-include::{include-path}mw.key[]
-
=== `{wollman}`
include::{include-path}wollman.key[]
-=== `{woodsb02}`
-include::{include-path}woodsb02.key[]
-
=== `{joerg}`
include::{include-path}joerg.key[]
-=== `{davidxu}`
-include::{include-path}davidxu.key[]
-
=== `{ygy}`
include::{include-path}ygy.key[]
=== `{emax}`
include::{include-path}emax.key[]
-=== `{yongari}`
-include::{include-path}yongari.key[]
-
-=== `{rcyu}`
-include::{include-path}rcyu.key[]
-
=== `{oshogbo}`
include::{include-path}oshogbo.key[]
@@ -1761,27 +1404,9 @@ include::{include-path}zeising.key[]
=== `{phantom}`
include::{include-path}phantom.key[]
-=== `{sephe}`
-include::{include-path}sephe.key[]
-
-=== `{mizhka}`
-include::{include-path}mizhka.key[]
-
-=== `{zont}`
-include::{include-path}zont.key[]
-
=== `{tz}`
include::{include-path}tz.key[]
-=== `{yuri}`
-include::{include-path}yuri.key[]
-
-=== `{slavash}`
-include::{include-path}slavash.key[]
-
-=== `{arrowd}`
-include::{include-path}arrowd.key[]
-
=== `{rigoletto}`
include::{include-path}rigoletto.key[]
@@ -1791,15 +1416,12 @@ include::{include-path}kaktus.key[]
=== `{samm}`
include::{include-path}samm.key[]
+=== `{arrowd}`
+include::{include-path}arrowd.key[]
+
[[pgpkeys-other]]
== Other Cluster Account Holders
-=== `{arundel}`
-include::{include-path}arundel.key[]
-
-=== `{bhaga}`
-include::{include-path}bhaga.key[]
-
=== `{bk}`
include::{include-path}bk.key[]
@@ -1815,9 +1437,6 @@ include::{include-path}dutchdaemon.key[]
=== `{keymaster}`
include::{include-path}keymaster.key[]
-=== `{plosher}`
-include::{include-path}plosher.key[]
-
=== `{mwlucas}`
include::{include-path}mwlucas.key[]
diff --git a/documentation/content/en/articles/problem-reports/_index.adoc b/documentation/content/en/articles/problem-reports/_index.adoc
index 24b63bb08a..81cf7c92f9 100644
--- a/documentation/content/en/articles/problem-reports/_index.adoc
+++ b/documentation/content/en/articles/problem-reports/_index.adoc
@@ -78,7 +78,7 @@ Consider these factors when submitting PRs about ports or other software that is
* Please do not submit problem reports that simply state that a newer version of an application is available. Ports maintainers are automatically notified by portscout when a new version of an application becomes available. Actual patches to update a port to the latest version are welcome.
* For unmaintained ports (`MAINTAINER` is `ports@FreeBSD.org`), a PR without an included patch is unlikely to get picked up by a committer. To become the maintainer of an unmaintained port, submit a PR with the request (patch preferred but not required).
-* In either case, following the process described in extref:{porters-handbook}[Porter's Handbook, port-upgrading] will yield the best results. (You might also wish to read extref:{contributing}[Contributing to the FreeBSD Ports Collection, ports-contributing].)
+* In either case, following the process described in extref:{porters-handbook}upgrading/[Porter's Handbook] will yield the best results. (You might also wish to read extref:{contributing}[Contributing to the FreeBSD Ports Collection, ports-contributing].)
A bug that cannot be reproduced can rarely be fixed.
If the bug only occurred once and you cannot reproduce it, and it does not seem to happen to anybody else, chances are none of the developers will be able to reproduce it or figure out what is wrong.
@@ -94,7 +94,7 @@ Next, to decide to whom you should file your problem report, you need to underst
Then, ascertain whether the problem is timely.
There are few things that will annoy a developer more than receiving a problem report about a bug she has already fixed.
-If the problem is in the base system, first read the FAQ section on extref:{faq}[FreeBSD versions, LATEST-VERSION], if you are not already familiar with the topic.
+If the problem is in the base system, first read the FAQ section on extref:{faq}[FreeBSD versions, latest-version], if you are not already familiar with the topic.
It is not possible for FreeBSD to fix problems in anything other than certain recent branches of the base system, so filing a bug report about an older version will probably only result in a developer advising you to upgrade to a supported version to see if the problem still recurs.
The Security Officer team maintains the link:https://www.FreeBSD.org/security/[list of supported versions].
@@ -110,7 +110,7 @@ You should therefore check all the obvious places before submitting your problem
For FreeBSD, this means:
* The FreeBSD extref:{faq}[Frequently Asked Questions] (FAQ) list. The FAQ attempts to provide answers for a wide range of questions, such as those concerning extref:{faq}[hardware compatibility, hardware], extref:{faq}[user applications, applications], and extref:{faq}[kernel configuration, kernelconfig].
-* The extref:{handbook}[mailing lists, eresources-mail]-if you are not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the searchable archives] on the FreeBSD web site. If the problem has not been discussed on the lists, you might try posting a message about it and waiting a few days to see if someone can spot something that has been overlooked.
+* The extref:{handbook}eresources/[mailing lists, eresources-mail]-if you are not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the searchable archives] on the FreeBSD web site. If the problem has not been discussed on the lists, you might try posting a message about it and waiting a few days to see if someone can spot something that has been overlooked.
* Optionally, the entire web-use your favorite search engine to locate any references to the problem. You may even get hits from archived mailing lists or newsgroups you did not know of or had not thought to search through.
* Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR database] (Bugzilla). Unless the problem is recent or obscure, there is a fair chance it has already been reported.
* Most importantly, attempt to see if existing documentation in the source base addresses your problem.
diff --git a/documentation/content/en/articles/vm-design/_index.adoc b/documentation/content/en/articles/vm-design/_index.adoc
index cac81535c5..7499c1e362 100644
--- a/documentation/content/en/articles/vm-design/_index.adoc
+++ b/documentation/content/en/articles/vm-design/_index.adoc
@@ -106,7 +106,7 @@ Data may be modified on a page-by-page basis whereas the file mapping encompasse
The complexity further increases when a process forks.
When a process forks, the result is two processes-each with their own private address spaces, including any modifications made by the original process prior to the call to `fork()`.
It would be silly for the VM system to make a complete copy of the data at the time of the `fork()` because it is quite possible that at least one of the two processes will only need to read from that page from then on, allowing the original page to continue to be used.
-What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not effect the other.
+What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not affect the other.
FreeBSD manages all of this with a layered VM Object model.
The original binary program file winds up being the lowest VM Object layer.
diff --git a/documentation/content/en/books/arch-handbook/_index.adoc b/documentation/content/en/books/arch-handbook/_index.adoc
index 777ef437e2..bb01f09331 100644
--- a/documentation/content/en/books/arch-handbook/_index.adoc
+++ b/documentation/content/en/books/arch-handbook/_index.adoc
@@ -50,6 +50,6 @@ Abstract
Welcome to the FreeBSD Architecture Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}.
-The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp].
+The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD download server] or one of the numerous extref:{handbook}[mirror sites, mirrors].
'''
diff --git a/documentation/content/en/books/arch-handbook/book.adoc b/documentation/content/en/books/arch-handbook/book.adoc
index d8993bdf12..15b9bdede4 100644
--- a/documentation/content/en/books/arch-handbook/book.adoc
+++ b/documentation/content/en/books/arch-handbook/book.adoc
@@ -49,7 +49,7 @@ Abstract
Welcome to the FreeBSD Architecture Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}.
-The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp].
+The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD download server] or one of the numerous extref:{handbook}[mirror sites, mirrors].
'''
diff --git a/documentation/content/en/books/arch-handbook/boot/_index.adoc b/documentation/content/en/books/arch-handbook/boot/_index.adoc
index ebed0609ca..cca516e445 100644
--- a/documentation/content/en/books/arch-handbook/boot/_index.adoc
+++ b/documentation/content/en/books/arch-handbook/boot/_index.adoc
@@ -50,18 +50,37 @@ endif::[]
[[boot-synopsis]]
== Synopsis
-This chapter is an overview of the boot and system initialization processes, starting from the BIOS (firmware) POST, to the first user process creation. Since the initial steps of system startup are very architecture dependent, the IA-32 architecture is used as an example.
+This chapter is an overview of the boot and system initialization processes, starting from the BIOS (firmware) POST, to the first user process creation.
+Since the initial steps of system startup are very architecture dependent, the IA-32 architecture is used as an example.
+But the AMD64 and ARM64 architectures are much more important and compelling examples and should be explained in the near future according to the topic of this document.
-The FreeBSD boot process can be surprisingly complex. After control is passed from the BIOS, a considerable amount of low-level configuration must be done before the kernel can be loaded and executed. This setup must be done in a simple and flexible manner, allowing the user a great deal of customization possibilities.
+The FreeBSD boot process can be surprisingly complex.
+After control is passed from the BIOS, a considerable amount of low-level configuration must be done before the kernel can be loaded and executed.
+This setup must be done in a simple and flexible manner, allowing the user a great deal of customization possibilities.
[[boot-overview]]
== Overview
-The boot process is an extremely machine-dependent activity. Not only must code be written for every computer architecture, but there may also be multiple types of booting on the same architecture. For example, a directory listing of [.filename]#/usr/src/sys/boot# reveals a great amount of architecture-dependent code. There is a directory for each of the various supported architectures. In the x86-specific [.filename]#i386# directory, there are subdirectories for different boot standards like [.filename]#mbr# (Master Boot Record), [.filename]#gpt# (GUID Partition Table), and [.filename]#efi# (Extensible Firmware Interface). Each boot standard has its own conventions and data structures. The example that follows shows booting an x86 computer from an MBR hard drive with the FreeBSD [.filename]#boot0# multi-boot loader stored in the very first sector. That boot code starts the FreeBSD three-stage boot process.
-
-The key to understanding this process is that it is a series of stages of increasing complexity. These stages are [.filename]#boot1#, [.filename]#boot2#, and [.filename]#loader# (see man:boot[8] for more detail). The boot system executes each stage in sequence. The last stage, [.filename]#loader#, is responsible for loading the FreeBSD kernel. Each stage is examined in the following sections.
-
-Here is an example of the output generated by the different boot stages. Actual output may differ from machine to machine:
+The boot process is an extremely machine-dependent activity.
+Not only must code be written for every computer architecture, but there may also be multiple types of booting on the same architecture.
+For example, a directory listing of [.filename]#stand# reveals a great amount of architecture-dependent code.
+There is a directory for each of the various supported architectures.
+FreeBSD supports the CSM boot standard (Compatibility Support Module).
+So CSM is supported (with both GPT and MBR partitioning support) and UEFI booting (GPT is totally supported, MBR is mostly supported).
+It also supports loading files from ext2fs, MSDOS, UFS and ZFS.
+FreeBSD also supports the boot environment feature of ZFS which allows the HOST OS to communicate details about what to boot that go beyond a simple partition as was possible in the past.
+But UEFI is more relevant than the CSM these days.
+The example that follows shows booting an x86 computer from an MBR-partitioned hard drive with the FreeBSD [.filename]#boot0# multi-boot loader stored in the very first sector.
+That boot code starts the FreeBSD three-stage boot process.
+
+The key to understanding this process is that it is a series of stages of increasing complexity.
+These stages are [.filename]#boot1#, [.filename]#boot2#, and [.filename]#loader# (see man:boot[8] for more detail).
+The boot system executes each stage in sequence.
+The last stage, [.filename]#loader#, is responsible for loading the FreeBSD kernel.
+Each stage is examined in the following sections.
+
+Here is an example of the output generated by the different boot stages.
+Actual output may differ from machine to machine:
[.informaltable]
[cols="20%,80%", frame="none"]
@@ -85,8 +104,8 @@ a|
[source,bash]
....
->>FreeBSD/i386 BOOT
-Default: 1:ad(1,a)/boot/loader
+>>FreeBSD/x86 BOOT
+Default: 0:ad(0p4)/boot/loader
boot:
....
@@ -102,7 +121,7 @@ BIOS 639kB/2096064kB available memory
FreeBSD/x86 bootstrap loader, Revision 1.1
Console internal video/keyboard
-(root@snap.freebsd.org, Thu Jan 16 22:18:05 UTC 2014)
+(root@releng1.nyi.freebsd.org, Fri Apr 9 04:04:45 UTC 2021)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0xed9008 data=0x117d28+0x176650 syms=[0x8+0x137988+0x8+0x1515f8]
....
@@ -112,13 +131,13 @@ a|
[source,bash]
....
-Copyright (c) 1992-2013 The FreeBSD Project.
+Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
-FreeBSD 10.0-RELEASE 0 r260789: Thu Jan 16 22:34:59 UTC 2014
- root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
-FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
+FreeBSD 13.0-RELEASE 0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:04:45 UTC 2021
+ root@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386
+FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
....
|===
@@ -126,26 +145,59 @@ FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
[[boot-bios]]
== The BIOS
-When the computer powers on, the processor's registers are set to some predefined values. One of the registers is the _instruction pointer_ register, and its value after a power on is well defined: it is a 32-bit value of `0xfffffff0`. The instruction pointer register (also known as the Program Counter) points to code to be executed by the processor. Another important register is the `cr0` 32-bit control register, and its value just after a reboot is `0`. One of ``cr0``'s bits, the PE (Protection Enabled) bit, indicates whether the processor is running in 32-bit protected mode or 16-bit real mode. Since this bit is cleared at boot time, the processor boots in 16-bit real mode. Real mode means, among other things, that linear and physical addresses are identical. The reason for the processor not to start immediately in 32-bit protected mode is backwards compatibility. In particular, the boot process relies on the services provided by the BIOS, and the BIOS itself works in legacy, 16-bit code.
-
-The value of `0xfffffff0` is slightly less than 4 GB, so unless the machine has 4 GB of physical memory, it cannot point to a valid memory address. The computer's hardware translates this address so that it points to a BIOS memory block.
-
-The BIOS (Basic Input Output System) is a chip on the motherboard that has a relatively small amount of read-only memory (ROM). This memory contains various low-level routines that are specific to the hardware supplied with the motherboard. The processor will first jump to the address 0xfffffff0, which really resides in the BIOS's memory. Usually this address contains a jump instruction to the BIOS's POST routines.
-
-The POST (Power On Self Test) is a set of routines including the memory check, system bus check, and other low-level initialization so the CPU can set up the computer properly. The important step of this stage is determining the boot device. Modern BIOS implementations permit the selection of a boot device, allowing booting from a floppy, CD-ROM, hard disk, or other devices.
-
-The very last thing in the POST is the `INT 0x19` instruction. The `INT 0x19` handler reads 512 bytes from the first sector of boot device into the memory at address `0x7c00`. The term _first sector_ originates from hard drive architecture, where the magnetic plate is divided into a number of cylindrical tracks. Tracks are numbered, and every track is divided into a number (usually 64) of sectors. Track numbers start at 0, but sector numbers start from 1. Track 0 is the outermost on the magnetic plate, and sector 1, the first sector, has a special purpose. It is also called the MBR, or Master Boot Record. The remaining sectors on the first track are never used.
-
-This sector is our boot-sequence starting point. As we will see, this sector contains a copy of our [.filename]#boot0# program. A jump is made by the BIOS to address `0x7c00` so it starts executing.
+When the computer powers on, the processor's registers are set to some predefined values.
+One of the registers is the _instruction pointer_ register, and its value after a power on is well defined: it is a 32-bit value of `0xfffffff0`.
+The instruction pointer register (also known as the Program Counter) points to code to be executed by the processor.
+Another important register is the `cr0` 32-bit control register, and its value just after a reboot is `0`.
+One of ``cr0``'s bits, the PE (Protection Enabled) bit, indicates whether the processor is running in 32-bit protected mode or 16-bit real mode.
+Since this bit is cleared at boot time, the processor boots in 16-bit real mode.
+Real mode means, among other things, that linear and physical addresses are identical.
+The reason for the processor not to start immediately in 32-bit protected mode is backwards compatibility.
+In particular, the boot process relies on the services provided by the BIOS, and the BIOS itself works in legacy, 16-bit code.
+
+The value of `0xfffffff0` is slightly less than 4 GB, so unless the machine has 4 GB of physical memory, it cannot point to a valid memory address.
+The computer's hardware translates this address so that it points to a BIOS memory block.
+
+The BIOS (Basic Input Output System) is a chip on the motherboard that has a relatively small amount of read-only memory (ROM).
+This memory contains various low-level routines that are specific to the hardware supplied with the motherboard.
+The processor will first jump to the address 0xfffffff0, which really resides in the BIOS's memory.
+Usually this address contains a jump instruction to the BIOS's POST routines.
+
+The POST (Power On Self Test) is a set of routines including the memory check, system bus check, and other low-level initialization so the CPU can set up the computer properly.
+The important step of this stage is determining the boot device.
+Modern BIOS implementations permit the selection of a boot device, allowing booting from a floppy, CD-ROM, hard disk, or other devices.
+
+The very last thing in the POST is the `INT 0x19` instruction.
+The `INT 0x19` handler reads 512 bytes from the first sector of boot device into the memory at address `0x7c00`.
+The term _first sector_ originates from hard drive architecture, where the magnetic plate is divided into a number of cylindrical tracks.
+Tracks are numbered, and every track is divided into a number (usually 64) of sectors.
+Track numbers start at 0, but sector numbers start from 1.
+Track 0 is the outermost on the magnetic plate, and sector 1, the first sector, has a special purpose.
+It is also called the MBR, or Master Boot Record.
+The remaining sectors on the first track are never used.
+
+This sector is our boot-sequence starting point.
+As we will see, this sector contains a copy of our [.filename]#boot0# program.
+A jump is made by the BIOS to address `0x7c00` so it starts executing.
[[boot-boot0]]
== The Master Boot Record (`boot0`)
-After control is received from the BIOS at memory address `0x7c00`, [.filename]#boot0# starts executing. It is the first piece of code under FreeBSD control. The task of [.filename]#boot0# is quite simple: scan the partition table and let the user choose which partition to boot from. The Partition Table is a special, standard data structure embedded in the MBR (hence embedded in [.filename]#boot0#) describing the four standard PC "partitions". [.filename]#boot0# resides in the filesystem as [.filename]#/boot/boot0#. It is a small 512-byte file, and it is exactly what FreeBSD's installation procedure wrote to the hard disk's MBR if you chose the "bootmanager" option at installation time. Indeed, [.filename]#boot0#_is_ the MBR.
+After control is received from the BIOS at memory address `0x7c00`, [.filename]#boot0# starts executing.
+It is the first piece of code under FreeBSD control.
+The task of [.filename]#boot0# is quite simple: scan the partition table and let the user choose which partition to boot from.
+The Partition Table is a special, standard data structure embedded in the MBR (hence embedded in [.filename]#boot0#) describing the four standard PC "partitions".
+[.filename]#boot0# resides in the filesystem as [.filename]#/boot/boot0#.
+It is a small 512-byte file, and it is exactly what FreeBSD's installation procedure wrote to the hard disk's MBR if you chose the "bootmanager" option at installation time.
+Indeed, [.filename]#boot0#_is_ the MBR.
-As mentioned previously, the `INT 0x19` instruction causes the `INT 0x19` handler to load an MBR ([.filename]#boot0#) into memory at address `0x7c00`. The source file for [.filename]#boot0# can be found in [.filename]#sys/boot/i386/boot0/boot0.S# - which is an awesome piece of code written by Robert Nordier.
+As mentioned previously, we're calling the BIOS `INT 0x19` to load the MBR ([.filename]#boot0#) into memory at address `0x7c00`.
+The source file for [.filename]#boot0# can be found in [.filename]#stand/i386/boot0/boot0.S# - which is an awesome piece of code written by Robert Nordier.
-A special structure starting from offset `0x1be` in the MBR is called the _partition table_. It has four records of 16 bytes each, called _partition records_, which represent how the hard disk is partitioned, or, in FreeBSD's terminology, sliced. One byte of those 16 says whether a partition (slice) is bootable or not. Exactly one record must have that flag set, otherwise [.filename]#boot0#'s code will refuse to proceed.
+A special structure starting from offset `0x1be` in the MBR is called the _partition table_.
+It has four records of 16 bytes each, called _partition records_, which represent how the hard disk is partitioned, or, in FreeBSD's terminology, sliced.
+One byte of those 16 says whether a partition (slice) is bootable or not.
+Exactly one record must have that flag set, otherwise [.filename]#boot0#'s code will refuse to proceed.
A partition record has the following fields:
@@ -154,27 +206,41 @@ A partition record has the following fields:
* the 6 byte descriptor in CHS format
* the 8 byte descriptor in LBA format
-A partition record descriptor contains information about where exactly the partition resides on the drive. Both descriptors, LBA and CHS, describe the same information, but in different ways: LBA (Logical Block Addressing) has the starting sector for the partition and the partition's length, while CHS (Cylinder Head Sector) has coordinates for the first and last sectors of the partition. The partition table ends with the special signature `0xaa55`.
+A partition record descriptor contains information about where exactly the partition resides on the drive.
+Both descriptors, LBA and CHS, describe the same information, but in different ways: LBA (Logical Block Addressing) has the starting sector for the partition and the partition's length, while CHS (Cylinder Head Sector) has coordinates for the first and last sectors of the partition.
+The partition table ends with the special signature `0xaa55`.
-The MBR must fit into 512 bytes, a single disk sector. This program uses low-level "tricks" like taking advantage of the side effects of certain instructions and reusing register values from previous operations to make the most out of the fewest possible instructions. Care must also be taken when handling the partition table, which is embedded in the MBR itself. For these reasons, be very careful when modifying [.filename]#boot0.S#.
+The MBR must fit into 512 bytes, a single disk sector.
+This program uses low-level "tricks" like taking advantage of the side effects of certain instructions and reusing register values from previous operations to make the most out of the fewest possible instructions.
+Care must also be taken when handling the partition table, which is embedded in the MBR itself.
+For these reasons, be very careful when modifying [.filename]#boot0.S#.
-Note that the [.filename]#boot0.S# source file is assembled "as is": instructions are translated one by one to binary, with no additional information (no ELF file format, for example). This kind of low-level control is achieved at link time through special control flags passed to the linker. For example, the text section of the program is set to be located at address `0x600`. In practice this means that [.filename]#boot0# must be loaded to memory address `0x600` in order to function properly.
+Note that the [.filename]#boot0.S# source file is assembled "as is": instructions are translated one by one to binary, with no additional information (no ELF file format, for example).
+This kind of low-level control is achieved at link time through special control flags passed to the linker.
+For example, the text section of the program is set to be located at address `0x600`.
+In practice this means that [.filename]#boot0# must be loaded to memory address `0x600` in order to function properly.
-It is worth looking at the [.filename]#Makefile# for [.filename]#boot0# ([.filename]#sys/boot/i386/boot0/Makefile#), as it defines some of the run-time behavior of [.filename]#boot0#. For instance, if a terminal connected to the serial port (COM1) is used for I/O, the macro `SIO` must be defined (`-DSIO`). `-DPXE` enables boot through PXE by pressing kbd:[F6]. Additionally, the program defines a set of _flags_ that allow further modification of its behavior. All of this is illustrated in the [.filename]#Makefile#. For example, look at the linker directives which command the linker to start the text section at address `0x600`, and to build the output file "as is" (strip out any file formatting):
+It is worth looking at the [.filename]#Makefile# for [.filename]#boot0# ([.filename]#stand/i386/boot0/Makefile#), as it defines some of the run-time behavior of [.filename]#boot0#.
+For instance, if a terminal connected to the serial port (COM1) is used for I/O, the macro `SIO` must be defined (`-DSIO`).
+`-DPXE` enables boot through PXE by pressing kbd:[F6].
+Additionally, the program defines a set of _flags_ that allow further modification of its behavior.
+All of this is illustrated in the [.filename]#Makefile#.
+For example, look at the linker directives which command the linker to start the text section at address `0x600`, and to build the output file "as is" (strip out any file formatting):
[.programlisting]
....
BOOT_BOOT0_ORG?=0x600
- LDFLAGS=-e start -Ttext ${BOOT_BOOT0_ORG} \
- -Wl,-N,-S,--oformat,binary
+ ORG=${BOOT_BOOT0_ORG}
....
-.[.filename]#sys/boot/i386/boot0/Makefile# [[boot-boot0-makefile-as-is]]
+.[.filename]#stand/i386/boot0/Makefile# [[boot-boot0-makefile-as-is]]
Let us now start our study of the MBR, or [.filename]#boot0#, starting where execution begins.
[NOTE]
====
-Some modifications have been made to some instructions in favor of better exposition. For example, some macros are expanded, and some macro tests are omitted when the result of the test is known. This applies to all of the code examples shown.
+Some modifications have been made to some instructions in favor of better exposition.
+For example, some macros are expanded, and some macro tests are omitted when the result of the test is known.
+This applies to all of the code examples shown.
====
[.programlisting]
@@ -185,47 +251,76 @@ start:
movw %ax,%es # Address
movw %ax,%ds # data
movw %ax,%ss # Set up
- movw 0x7c00,%sp # stack
+ movw $LOAD,%sp # stack
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-entrypoint]]
-This first block of code is the entry point of the program. It is where the BIOS transfers control. First, it makes sure that the string operations autoincrement its pointer operands (the `cld` instruction) footnote:[When in doubt, we refer the reader to the official Intel manuals, which describe the exact semantics for each instruction: .]. Then, as it makes no assumption about the state of the segment registers, it initializes them. Finally, it sets the stack pointer register (`%sp`) to address `0x7c00`, so we have a working stack.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-entrypoint]]
+This first block of code is the entry point of the program.
+It is where the BIOS transfers control.
+First, it makes sure that the string operations autoincrement its pointer operands (the `cld` instruction) footnote:[When in doubt, we refer the reader to the official Intel manuals, which describe the exact semantics for each instruction: .].
+Then, as it makes no assumption about the state of the segment registers, it initializes them.
+Finally, it sets the stack pointer register (`%sp`) to ($LOAD = address `0x7c00`), so we have a working stack.
The next block is responsible for the relocation and subsequent jump to the relocated code.
[.programlisting]
....
- movw $0x7c00,%si # Source
- movw $0x600,%di # Destination
- movw $512,%cx # Word count
+ movw %sp,%si # Source
+ movw $start,%di # Destination
+ movw $0x100,%cx # Word count
rep # Relocate
- movsb # code
+ movsw # code
movw %di,%bp # Address variables
- movb $16,%cl # Words to clear
+ movb $0x8,%cl # Words to clear
rep # Zero
- stosb # them
+ stosw # them
incb -0xe(%di) # Set the S field to 1
- jmp main-0x7c00+0x600 # Jump to relocated code
-....
-
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-relocation]]
-As [.filename]#boot0# is loaded by the BIOS to address `0x7C00`, it copies itself to address `0x600` and then transfers control there (recall that it was linked to execute at address `0x600`). The source address, `0x7c00`, is copied to register `%si`. The destination address, `0x600`, to register `%di`. The number of bytes to copy, `512` (the program's size), is copied to register `%cx`. Next, the `rep` instruction repeats the instruction that follows, that is, `movsb`, the number of times dictated by the `%cx` register. The `movsb` instruction copies the byte pointed to by `%si` to the address pointed to by `%di`. This is repeated another 511 times. On each repetition, both the source and destination registers, `%si` and `%di`, are incremented by one. Thus, upon completion of the 512-byte copy, `%di` has the value `0x600`+`512`= `0x800`, and `%si` has the value `0x7c00`+`512`= `0x7e00`; we have thus completed the code _relocation_.
-
-Next, the destination register `%di` is copied to `%bp`. `%bp` gets the value `0x800`. The value `16` is copied to `%cl` in preparation for a new string operation (like our previous `movsb`). Now, `stosb` is executed 16 times. This instruction copies a `0` value to the address pointed to by the destination register (`%di`, which is `0x800`), and increments it. This is repeated another 15 times, so `%di` ends up with value `0x810`. Effectively, this clears the address range `0x800`-`0x80f`. This range is used as a (fake) partition table for writing the MBR back to disk. Finally, the sector field for the CHS addressing of this fake partition is given the value 1 and a jump is made to the main function from the relocated code. Note that until this jump to the relocated code, any reference to an absolute address was avoided.
+ jmp main-LOAD+ORIGIN # Jump to relocated code
+....
+
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-relocation]]
+As [.filename]#boot0# is loaded by the BIOS to address `0x7C00`, it copies itself to address `0x600` and then transfers control there (recall that it was linked to execute at address `0x600`).
+The source address, `0x7c00`, is copied to register `%si`.
+The destination address, `0x600`, to register `%di`.
+The number of words to copy, `256` (the program's size = 512 bytes), is copied to register `%cx`.
+Next, the `rep` instruction repeats the instruction that follows, that is, `movsw`, the number of times dictated by the `%cx` register.The `movsw` instruction copies the word pointed to by `%si` to the address pointed to by `%di`.
+This is repeated another 255 times.
+On each repetition, both the source and destination registers, `%si` and `%di`, are incremented by one.
+Thus, upon completion of the 256-word (512-byte) copy, `%di` has the value `0x600`+`512`= `0x800`, and `%si` has the value `0x7c00`+`512`= `0x7e00`; we have thus completed the code _relocation_.
+Since the last update of this document, the copy instructions have changed in the code, so instead of the movsb and stosb, movsw and stosw have been introduced, which copy 2 bytes(1 word) in one iteration.
+
+Next, the destination register `%di` is copied to `%bp`.
+`%bp` gets the value `0x800`.
+The value `8` is copied to `%cl` in preparation for a new string operation (like our previous `movsw`).
+Now, `stosw` is executed 8 times.
+This instruction copies a `0` value to the address pointed to by the destination register (`%di`, which is `0x800`), and increments it.
+This is repeated another 7 times, so `%di` ends up with value `0x810`.
+Effectively, this clears the address range `0x800`-`0x80f`.
+This range is used as a (fake) partition table for writing the MBR back to disk.Finally, the sector field for the CHS addressing of this fake partition is given the value 1 and a jump is made to the main function from the relocated code.
+Note that until this jump to the relocated code, any reference to an absolute address was avoided.
The following code block tests whether the drive number provided by the BIOS should be used, or the one stored in [.filename]#boot0#.
[.programlisting]
....
main:
- testb $SETDRV,-69(%bp) # Set drive number?
+ testb $SETDRV,_FLAGS(%bp) # Set drive number?
+#ifndef CHECK_DRIVE /* disable drive checks */
+ jz save_curdrive # no, use the default
+#else
jnz disable_update # Yes
testb %dl,%dl # Drive number valid?
js save_curdrive # Possibly (0x80 set)
+#endif
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-drivenumber]]
-This code tests the `SETDRV` bit (`0x20`) in the _flags_ variable. Recall that register `%bp` points to address location `0x800`, so the test is done to the _flags_ variable at address `0x800`-`69`= `0x7bb`. This is an example of the type of modifications that can be done to [.filename]#boot0#. The `SETDRV` flag is not set by default, but it can be set in the [.filename]#Makefile#. When set, the drive number stored in the MBR is used instead of the one provided by the BIOS. We assume the defaults, and that the BIOS provided a valid drive number, so we jump to `save_curdrive`.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-drivenumber]]
+This code tests the `SETDRV` bit (`0x20`) in the _flags_ variable.
+Recall that register `%bp` points to address location `0x800`, so the test is done to the _flags_ variable at address `0x800`-`69`= `0x7bb`.
+This is an example of the type of modifications that can be done to [.filename]#boot0#.
+The `SETDRV` flag is not set by default, but it can be set in the [.filename]#Makefile#.
+When set, the drive number stored in the MBR is used instead of the one provided by the BIOS.
+We assume the defaults, and that the BIOS provided a valid drive number, so we jump to `save_curdrive`.
The next block saves the drive number provided by the BIOS, and calls `putn` to print a new line on the screen.
@@ -242,10 +337,14 @@ save_curdrive:
callw putn # Print a newline
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-savedrivenumber]]
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-savedrivenumber]]
Note that we assume `TEST` is not defined, so the conditional code in it is not assembled and will not appear in our executable [.filename]#boot0#.
-Our next block implements the actual scanning of the partition table. It prints to the screen the partition type for each of the four entries in the partition table. It compares each type with a list of well-known operating system file systems. Examples of recognized partition types are NTFS (Windows(R), ID 0x7), `ext2fs` (Linux(R), ID 0x83), and, of course, `ffs`/`ufs2` (FreeBSD, ID 0xa5). The implementation is fairly simple.
+Our next block implements the actual scanning of the partition table.
+It prints to the screen the partition type for each of the four entries in the partition table.
+It compares each type with a list of well-known operating system file systems.
+Examples of recognized partition types are NTFS (Windows(R), ID 0x7), `ext2fs` (Linux(R), ID 0x83), and, of course, `ffs`/`ufs2` (FreeBSD, ID 0xa5).
+The implementation is fairly simple.
[.programlisting]
....
@@ -274,23 +373,29 @@ next_entry:
jnc read_entry # Till done
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-partition-scan]]
-It is important to note that the active flag for each entry is cleared, so after the scanning, _no_ partition entry is active in our memory copy of [.filename]#boot0#. Later, the active flag will be set for the selected partition. This ensures that only one active partition exists if the user chooses to write the changes back to disk.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-partition-scan]]
+It is important to note that the active flag for each entry is cleared, so after the scanning, _no_ partition entry is active in our memory copy of [.filename]#boot0#.
+Later, the active flag will be set for the selected partition.
+This ensures that only one active partition exists if the user chooses to write the changes back to disk.
-The next block tests for other drives. At startup, the BIOS writes the number of drives present in the computer to address `0x475`. If there are any other drives present, [.filename]#boot0# prints the current drive to screen. The user may command [.filename]#boot0# to scan partitions on another drive later.
+The next block tests for other drives.
+At startup, the BIOS writes the number of drives present in the computer to address `0x475`.
+If there are any other drives present, [.filename]#boot0# prints the current drive to screen.
+The user may command [.filename]#boot0# to scan partitions on another drive later.
[.programlisting]
....
popw %ax # Drive number
- subb $0x79,%al # Does next
- cmpb 0x475,%al # drive exist? (from BIOS?)
+ subb $0x80-0x1,%al # Does next
+ cmpb NHRDRV,%al # drive exist? (from BIOS?)
jb print_drive # Yes
decw %ax # Already drive 0?
jz print_prompt # Yes
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-test-drives]]
-We make the assumption that a single drive is present, so the jump to `print_drive` is not performed. We also assume nothing strange happened, so we jump to `print_prompt`.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-test-drives]]
+We make the assumption that a single drive is present, so the jump to `print_drive` is not performed.
+We also assume nothing strange happened, so we jump to `print_prompt`.
This next block just prints out a prompt followed by the default option:
@@ -305,7 +410,7 @@ print_prompt:
jmp start_input # Skip beep
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-prompt]]
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-prompt]]
Finally, a jump is performed to `start_input`, where the BIOS services are used to start a timer and for reading user input from the keyboard; if the timer expires, the default option will be selected:
[.programlisting]
@@ -325,20 +430,37 @@ read_key:
jb read_key # No
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-start-input]]
-An interrupt is requested with number `0x1a` and argument `0` in register `%ah`. The BIOS has a predefined set of services, requested by applications as software-generated interrupts through the `int` instruction and receiving arguments in registers (in this case, `%ah`). Here, particularly, we are requesting the number of clock ticks since last midnight; this value is computed by the BIOS through the RTC (Real Time Clock). This clock can be programmed to work at frequencies ranging from 2 Hz to 8192 Hz. The BIOS sets it to 18.2 Hz at startup. When the request is satisfied, a 32-bit result is returned by the BIOS in registers `%cx` and `%dx` (lower bytes in `%dx`). This result (the `%dx` part) is copied to register `%di`, and the value of the `TICKS` variable is added to `%di`. This variable resides in [.filename]#boot0# at offset `_TICKS` (a negative value) from register `%bp` (which, recall, points to `0x800`). The default value of this variable is `0xb6` (182 in decimal). Now, the idea is that [.filename]#boot0# constantly requests the time from the BIOS, and when the value returned in register `%dx` is greater than the value stored in `%di`, the time is up and the default selection will be made. Since the RTC ticks 18.2 times per second, this condition will be met after 10 seconds (this default behavior can be changed in the [.filename]#Makefile#). Until this time has passed, [.filename]#boot0# continually asks the BIOS for any user input; this is done through `int 0x16`, argument `1` in `%ah`.
-
-Whether a key was pressed or the time expired, subsequent code validates the selection. Based on the selection, the register `%si` is set to point to the appropriate partition entry in the partition table. This new selection overrides the previous default one. Indeed, it becomes the new default. Finally, the ACTIVE flag of the selected partition is set. If it was enabled at compile time, the in-memory version of [.filename]#boot0# with these modified values is written back to the MBR on disk. We leave the details of this implementation to the reader.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-start-input]]
+An interrupt is requested with number `0x1a` and argument `0` in register `%ah`.
+The BIOS has a predefined set of services, requested by applications as software-generated interrupts through the `int` instruction and receiving arguments in registers (in this case, `%ah`).
+Here, particularly, we are requesting the number of clock ticks since last midnight; this value is computed by the BIOS through the RTC (Real Time Clock).
+This clock can be programmed to work at frequencies ranging from 2 Hz to 8192 Hz.
+The BIOS sets it to 18.2 Hz at startup.
+When the request is satisfied, a 32-bit result is returned by the BIOS in registers `%cx` and `%dx` (lower bytes in `%dx`).
+This result (the `%dx` part) is copied to register `%di`, and the value of the `TICKS` variable is added to `%di`.
+This variable resides in [.filename]#boot0# at offset `_TICKS` (a negative value) from register `%bp` (which, recall, points to `0x800`).
+The default value of this variable is `0xb6` (182 in decimal).
+Now, the idea is that [.filename]#boot0# constantly requests the time from the BIOS, and when the value returned in register `%dx` is greater than the value stored in `%di`, the time is up and the default selection will be made.
+Since the RTC ticks 18.2 times per second, this condition will be met after 10 seconds (this default behavior can be changed in the [.filename]#Makefile#).
+Until this time has passed, [.filename]#boot0# continually asks the BIOS for any user input; this is done through `int 0x16`, argument `1` in `%ah`.
+
+Whether a key was pressed or the time expired, subsequent code validates the selection.
+Based on the selection, the register `%si` is set to point to the appropriate partition entry in the partition table.
+This new selection overrides the previous default one.
+Indeed, it becomes the new default.
+Finally, the ACTIVE flag of the selected partition is set.
+If it was enabled at compile time, the in-memory version of [.filename]#boot0# with these modified values is written back to the MBR on disk.
+We leave the details of this implementation to the reader.
We now end our study with the last code block from the [.filename]#boot0# program:
[.programlisting]
....
- movw $0x7c00,%bx # Address for read
+ movw $LOAD,%bx # Address for read
movb $0x2,%ah # Read sector
callw intx13 # from disk
jc beep # If error
- cmpw $0xaa55,0x1fe(%bx) # Bootable?
+ cmpw $MAGIC,0x1fe(%bx) # Bootable?
jne beep # No
pushw %si # Save ptr to selected part.
callw putn # Leave some space
@@ -346,27 +468,50 @@ We now end our study with the last code block from the [.filename]#boot0# progra
jmp *%bx # Invoke bootstrap
....
-.[.filename]#sys/boot/i386/boot0/boot0.S# [[boot-boot0-check-bootable]]
-Recall that `%si` points to the selected partition entry. This entry tells us where the partition begins on disk. We assume, of course, that the partition selected is actually a FreeBSD slice.
+.[.filename]#stand/i386/boot0/boot0.S# [[boot-boot0-check-bootable]]
+Recall that `%si` points to the selected partition entry.
+This entry tells us where the partition begins on disk.
+We assume, of course, that the partition selected is actually a FreeBSD slice.
[NOTE]
====
From now on, we will favor the use of the technically more accurate term "slice" rather than "partition".
====
-The transfer buffer is set to `0x7c00` (register `%bx`), and a read for the first sector of the FreeBSD slice is requested by calling `intx13`. We assume that everything went okay, so a jump to `beep` is not performed. In particular, the new sector read must end with the magic sequence `0xaa55`. Finally, the value at `%si` (the pointer to the selected partition table) is preserved for use by the next stage, and a jump is performed to address `0x7c00`, where execution of our next stage (the just-read block) is started.
+The transfer buffer is set to `0x7c00` (register `%bx`), and a read for the first sector of the FreeBSD slice is requested by calling `intx13`.
+We assume that everything went okay, so a jump to `beep` is not performed.
+In particular, the new sector read must end with the magic sequence `0xaa55`.
+Finally, the value at `%si` (the pointer to the selected partition table) is preserved for use by the next stage, and a jump is performed to address `0x7c00`, where execution of our next stage (the just-read block) is started.
[[boot-boot1]]
== `boot1` Stage
So far we have gone through the following sequence:
-* The BIOS did some early hardware initialization, including the POST. The MBR ([.filename]#boot0#) was loaded from absolute disk sector one to address `0x7c00`. Execution control was passed to that location.
-* [.filename]#boot0# relocated itself to the location it was linked to execute (`0x600`), followed by a jump to continue execution at the appropriate place. Finally, [.filename]#boot0# loaded the first disk sector from the FreeBSD slice to address `0x7c00`. Execution control was passed to that location.
-
-[.filename]#boot1# is the next step in the boot-loading sequence. It is the first of three boot stages. Note that we have been dealing exclusively with disk sectors. Indeed, the BIOS loads the absolute first sector, while [.filename]#boot0# loads the first sector of the FreeBSD slice. Both loads are to address `0x7c00`. We can conceptually think of these disk sectors as containing the files [.filename]#boot0# and [.filename]#boot1#, respectively, but in reality this is not entirely true for [.filename]#boot1#. Strictly speaking, unlike [.filename]#boot0#, [.filename]#boot1# is not part of the boot blocks footnote:[There is a file /boot/boot1, but it is not the written to the beginning of the FreeBSD slice. Instead, it is concatenated with boot2 to form boot, which is written to the beginning of the FreeBSD slice and read at boot time.]. Instead, a single, full-blown file, [.filename]#boot# ([.filename]#/boot/boot#), is what ultimately is written to disk. This file is a combination of [.filename]#boot1#, [.filename]#boot2# and the `Boot Extender` (or BTX). This single file is greater in size than a single sector (greater than 512 bytes). Fortunately, [.filename]#boot1# occupies _exactly_ the first 512 bytes of this single file, so when [.filename]#boot0# loads the first sector of the FreeBSD slice (512 bytes), it is actually loading [.filename]#boot1# and transferring control to it.
-
-The main task of [.filename]#boot1# is to load the next boot stage. This next stage is somewhat more complex. It is composed of a server called the "Boot Extender", or BTX, and a client, called [.filename]#boot2#. As we will see, the last boot stage, [.filename]#loader#, is also a client of the BTX server.
+* The BIOS did some early hardware initialization, including the POST.
+The MBR ([.filename]#boot0#) was loaded from absolute disk sector one to address `0x7c00`.
+Execution control was passed to that location.
+* [.filename]#boot0# relocated itself to the location it was linked to execute (`0x600`), followed by a jump to continue execution at the appropriate place.
+Finally, [.filename]#boot0# loaded the first disk sector from the FreeBSD slice to address `0x7c00`.
+Execution control was passed to that location.
+
+[.filename]#boot1# is the next step in the boot-loading sequence.
+It is the first of three boot stages.
+Note that we have been dealing exclusively with disk sectors.
+Indeed, the BIOS loads the absolute first sector, while [.filename]#boot0# loads the first sector of the FreeBSD slice.
+Both loads are to address `0x7c00`.
+We can conceptually think of these disk sectors as containing the files [.filename]#boot0# and [.filename]#boot1#, respectively, but in reality this is not entirely true for [.filename]#boot1#.
+Strictly speaking, unlike [.filename]#boot0#, [.filename]#boot1# is not part of the boot blocks footnote:[There is a file /boot/boot1, but it is not the written to the beginning of the FreeBSD slice.
+Instead, it is concatenated with boot2 to form boot, which is written to the beginning of the FreeBSD slice and read at boot time.].
+Instead, a single, full-blown file, [.filename]#boot# ([.filename]#/boot/boot#), is what ultimately is written to disk.
+This file is a combination of [.filename]#boot1#, [.filename]#boot2# and the `Boot Extender` (or BTX).
+This single file is greater in size than a single sector (greater than 512 bytes).
+Fortunately, [.filename]#boot1# occupies _exactly_ the first 512 bytes of this single file, so when [.filename]#boot0# loads the first sector of the FreeBSD slice (512 bytes), it is actually loading [.filename]#boot1# and transferring control to it.
+
+The main task of [.filename]#boot1# is to load the next boot stage.
+This next stage is somewhat more complex.
+It is composed of a server called the "Boot Extender", or BTX, and a client, called [.filename]#boot2#.
+As we will see, the last boot stage, [.filename]#loader#, is also a client of the BTX server.
Let us now look in detail at what exactly is done by [.filename]#boot1#, starting like we did for [.filename]#boot0#, at its entry point:
@@ -376,7 +521,7 @@ start:
jmp main
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-entry]]
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-entry]]
The entry point at `start` simply jumps past a special data area to the label `main`, which in turn looks like this:
[.programlisting]
@@ -389,16 +534,22 @@ main:
mov %cx,%ss # Set up
mov $start,%sp # stack
mov %sp,%si # Source
- mov $0x700,%di # Destination
+ mov $MEM_REL,%di # Destination
incb %ch # Word count
rep # Copy
movsw # code
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-main]]
-Just like [.filename]#boot0#, this code relocates [.filename]#boot1#, this time to memory address `0x700`. However, unlike [.filename]#boot0#, it does not jump there. [.filename]#boot1# is linked to execute at address `0x7c00`, effectively where it was loaded in the first place. The reason for this relocation will be discussed shortly.
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-main]]
+Just like [.filename]#boot0#, this code relocates [.filename]#boot1#, this time to memory address `0x700`.
+However, unlike [.filename]#boot0#, it does not jump there.
+[.filename]#boot1# is linked to execute at address `0x7c00`, effectively where it was loaded in the first place.
+The reason for this relocation will be discussed shortly.
-Next comes a loop that looks for the FreeBSD slice. Although [.filename]#boot0# loaded [.filename]#boot1# from the FreeBSD slice, no information was passed to it about this footnote:[Actually we did pass a pointer to the slice entry in register %si. However, boot1 does not assume that it was loaded by boot0 (perhaps some other MBR loaded it, and did not pass this information), so it assumes nothing.], so [.filename]#boot1# must rescan the partition table to find where the FreeBSD slice starts. Therefore it rereads the MBR:
+Next comes a loop that looks for the FreeBSD slice.
+Although [.filename]#boot0# loaded [.filename]#boot1# from the FreeBSD slice, no information was passed to it about this footnote:[Actually we did pass a pointer to the slice entry in register %si.
+However, boot1 does not assume that it was loaded by boot0 (perhaps some other MBR loaded it, and did not pass this information), so it assumes nothing.], so [.filename]#boot1# must rescan the partition table to find where the FreeBSD slice starts.
+Therefore it rereads the MBR:
[.programlisting]
....
@@ -409,8 +560,14 @@ Next comes a loop that looks for the FreeBSD slice. Although [.filename]#boot0#
callw nread # Read MBR
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-find-freebsd]]
-In the code above, register `%dl` maintains information about the boot device. This is passed on by the BIOS and preserved by the MBR. Numbers `0x80` and greater tells us that we are dealing with a hard drive, so a call is made to `nread`, where the MBR is read. Arguments to `nread` are passed through `%si` and `%dh`. The memory address at label `part4` is copied to `%si`. This memory address holds a "fake partition" to be used by `nread`. The following is the data in the fake partition:
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-find-freebsd]]
+In the code above, register `%dl` maintains information about the boot device.
+This is passed on by the BIOS and preserved by the MBR.
+Numbers `0x80` and greater tells us that we are dealing with a hard drive, so a call is made to `nread`, where the MBR is read.
+Arguments to `nread` are passed through `%si` and `%dh`.
+The memory address at label `part4` is copied to `%si`.
+This memory address holds a "fake partition" to be used by `nread`.
+The following is the data in the fake partition:
[.programlisting]
....
@@ -421,15 +578,18 @@ In the code above, register `%dl` maintains information about the boot device. T
.byte 0x50, 0xc3, 0x00, 0x00
....
-.[.filename]#sys/boot/i386/boot2/Makefile# [[boot-boot2-make-fake-partition]]
-In particular, the LBA for this fake partition is hardcoded to zero. This is used as an argument to the BIOS for reading absolute sector one from the hard drive. Alternatively, CHS addressing could be used. In this case, the fake partition holds cylinder 0, head 0 and sector 1, which is equivalent to absolute sector one.
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot2-make-fake-partition]]
+In particular, the LBA for this fake partition is hardcoded to zero.
+This is used as an argument to the BIOS for reading absolute sector one from the hard drive.
+Alternatively, CHS addressing could be used.
+In this case, the fake partition holds cylinder 0, head 0 and sector 1, which is equivalent to absolute sector one.
Let us now proceed to take a look at `nread`:
[.programlisting]
....
nread:
- mov $0x8c00,%bx # Transfer buffer
+ mov $MEM_BUF,%bx # Transfer buffer
mov 0x8(%si),%ax # Get
mov 0xa(%si),%cx # LBA
push %cs # Read from
@@ -437,8 +597,15 @@ nread:
jnc return # If success, return
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-nread]]
-Recall that `%si` points to the fake partition. The word footnote:[In the context of 16-bit real mode, a word is 2 bytes.] at offset `0x8` is copied to register `%ax` and word at offset `0xa` to `%cx`. They are interpreted by the BIOS as the lower 4-byte value denoting the LBA to be read (the upper four bytes are assumed to be zero). Register `%bx` holds the memory address where the MBR will be loaded. The instruction pushing `%cs` onto the stack is very interesting. In this context, it accomplishes nothing. However, as we will see shortly, [.filename]#boot2#, in conjunction with the BTX server, also uses `xread.1`. This mechanism will be discussed in the next section.
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-nread]]
+Recall that `%si` points to the fake partition.
+The word footnote:[In the context of 16-bit real mode, a word is 2 bytes.] at offset `0x8` is copied to register `%ax` and word at offset `0xa` to `%cx`.
+They are interpreted by the BIOS as the lower 4-byte value denoting the LBA to be read (the upper four bytes are assumed to be zero).
+Register `%bx` holds the memory address where the MBR will be loaded.
+The instruction pushing `%cs` onto the stack is very interesting.
+In this context, it accomplishes nothing.
+However, as we will see shortly, [.filename]#boot2#, in conjunction with the BTX server, also uses `xread.1`.
+This mechanism will be discussed in the next section.
The code at `xread.1` further calls the `read` function, which actually calls the BIOS asking for the disk sector:
@@ -460,8 +627,10 @@ xread.1:
lret # To far caller
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-xread1]]
-Note the long return instruction at the end of this block. This instruction pops out the `%cs` register pushed by `nread`, and returns. Finally, `nread` also returns.
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-xread1]]
+Note the long return instruction at the end of this block.
+This instruction pops out the `%cs` register pushed by `nread`, and returns.
+Finally, `nread` also returns.
With the MBR loaded to memory, the actual loop for searching the FreeBSD slice begins:
@@ -469,10 +638,10 @@ With the MBR loaded to memory, the actual loop for searching the FreeBSD slice b
....
mov $0x1,%cx # Two passes
main.1:
- mov $0x8dbe,%si # Partition table
+ mov $MEM_BUF+PRT_OFF,%si # Partition table
movb $0x1,%dh # Partition
main.2:
- cmpb $0xa5,0x4(%si) # Our partition type?
+ cmpb $PRT_BSD,0x4(%si) # Our partition type?
jne main.3 # No
jcxz main.5 # If second pass
testb $0x80,(%si) # Active?
@@ -480,33 +649,39 @@ main.2:
main.3:
add $0x10,%si # Next entry
incb %dh # Partition
- cmpb $0x5,%dh # In table?
+ cmpb $0x1+PRT_NUM,%dh # In table?
jb main.2 # Yes
dec %cx # Do two
jcxz main.1 # passes
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-find-part]]
-If a FreeBSD slice is identified, execution continues at `main.5`. Note that when a FreeBSD slice is found `%si` points to the appropriate entry in the partition table, and `%dh` holds the partition number. We assume that a FreeBSD slice is found, so we continue execution at `main.5`:
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-find-part]]
+If a FreeBSD slice is identified, execution continues at `main.5`.
+Note that when a FreeBSD slice is found `%si` points to the appropriate entry in the partition table, and `%dh` holds the partition number.
+We assume that a FreeBSD slice is found, so we continue execution at `main.5`:
[.programlisting]
....
main.5:
- mov %dx,0x900 # Save args
- movb $0x10,%dh # Sector count
+ mov %dx,MEM_ARG # Save args
+ movb $NSECT,%dh # Sector count
callw nread # Read disk
- mov $0x9000,%bx # BTX
+ mov $MEM_BTX,%bx # BTX
mov 0xa(%bx),%si # Get BTX length and set
add %bx,%si # %si to start of boot2.bin
- mov $0xc000,%di # Client page 2
- mov $0xa200,%cx # Byte
+ mov $MEM_USR+SIZ_PAG*2,%di # Client page 2
+ mov $MEM_BTX+(NSECT-1)*SIZ_SEC,%cx # Byte
sub %si,%cx # count
rep # Relocate
movsb # client
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-main5]]
-Recall that at this point, register `%si` points to the FreeBSD slice entry in the MBR partition table, so a call to `nread` will effectively read sectors at the beginning of this partition. The argument passed on register `%dh` tells `nread` to read 16 disk sectors. Recall that the first 512 bytes, or the first sector of the FreeBSD slice, coincides with the [.filename]#boot1# program. Also recall that the file written to the beginning of the FreeBSD slice is not [.filename]#/boot/boot1#, but [.filename]#/boot/boot#. Let us look at the size of these files in the filesystem:
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-main5]]
+Recall that at this point, register `%si` points to the FreeBSD slice entry in the MBR partition table, so a call to `nread` will effectively read sectors at the beginning of this partition.
+The argument passed on register `%dh` tells `nread` to read 16 disk sectors.
+Recall that the first 512 bytes, or the first sector of the FreeBSD slice, coincides with the [.filename]#boot1# program.
+Also recall that the file written to the beginning of the FreeBSD slice is not [.filename]#/boot/boot1#, but [.filename]#/boot/boot#.
+Let us look at the size of these files in the filesystem:
[source,bash]
....
@@ -516,15 +691,33 @@ Recall that at this point, register `%si` points to the FreeBSD slice entry in t
-r--r--r-- 1 root wheel 8.0K Jan 8 00:15 /boot/boot
....
-Both [.filename]#boot0# and [.filename]#boot1# are 512 bytes each, so they fit _exactly_ in one disk sector. [.filename]#boot2# is much bigger, holding both the BTX server and the [.filename]#boot2# client. Finally, a file called simply [.filename]#boot# is 512 bytes larger than [.filename]#boot2#. This file is a concatenation of [.filename]#boot1# and [.filename]#boot2#. As already noted, [.filename]#boot0# is the file written to the absolute first disk sector (the MBR), and [.filename]#boot# is the file written to the first sector of the FreeBSD slice; [.filename]#boot1# and [.filename]#boot2# are _not_ written to disk. The command used to concatenate [.filename]#boot1# and [.filename]#boot2# into a single [.filename]#boot# is merely `cat boot1 boot2 > boot`.
+Both [.filename]#boot0# and [.filename]#boot1# are 512 bytes each, so they fit _exactly_ in one disk sector.
+[.filename]#boot2# is much bigger, holding both the BTX server and the [.filename]#boot2# client.
+Finally, a file called simply [.filename]#boot# is 512 bytes larger than [.filename]#boot2#.
+This file is a concatenation of [.filename]#boot1# and [.filename]#boot2#.
+As already noted, [.filename]#boot0# is the file written to the absolute first disk sector (the MBR), and [.filename]#boot# is the file written to the first sector of the FreeBSD slice; [.filename]#boot1# and [.filename]#boot2# are _not_ written to disk.
+The command used to concatenate [.filename]#boot1# and [.filename]#boot2# into a single [.filename]#boot# is merely `cat boot1 boot2 > boot`.
-So [.filename]#boot1# occupies exactly the first 512 bytes of [.filename]#boot# and, because [.filename]#boot# is written to the first sector of the FreeBSD slice, [.filename]#boot1# fits exactly in this first sector. When `nread` reads the first 16 sectors of the FreeBSD slice, it effectively reads the entire [.filename]#boot# file footnote:[512*16=8192 bytes, exactly the size of boot]. We will see more details about how [.filename]#boot# is formed from [.filename]#boot1# and [.filename]#boot2# in the next section.
+So [.filename]#boot1# occupies exactly the first 512 bytes of [.filename]#boot# and, because [.filename]#boot# is written to the first sector of the FreeBSD slice, [.filename]#boot1# fits exactly in this first sector.
+When `nread` reads the first 16 sectors of the FreeBSD slice, it effectively reads the entire [.filename]#boot# file footnote:[512*16=8192 bytes, exactly the size of boot].
+We will see more details about how [.filename]#boot# is formed from [.filename]#boot1# and [.filename]#boot2# in the next section.
-Recall that `nread` uses memory address `0x8c00` as the transfer buffer to hold the sectors read. This address is conveniently chosen. Indeed, because [.filename]#boot1# belongs to the first 512 bytes, it ends up in the address range `0x8c00`-`0x8dff`. The 512 bytes that follows (range `0x8e00`-`0x8fff`) is used to store the _bsdlabel_ footnote:[Historically known as disklabel. If you ever wondered where FreeBSD stored this information, it is in this region. See man:bsdlabel[8]].
+Recall that `nread` uses memory address `0x8c00` as the transfer buffer to hold the sectors read.
+This address is conveniently chosen.
+Indeed, because [.filename]#boot1# belongs to the first 512 bytes, it ends up in the address range `0x8c00`-`0x8dff`.
+The 512 bytes that follows (range `0x8e00`-`0x8fff`) is used to store the _bsdlabel_ footnote:[Historically known as disklabel.
+If you ever wondered where FreeBSD stored this information, it is in this region - see man:bsdlabel[8]].
-Starting at address `0x9000` is the beginning of the BTX server, and immediately following is the [.filename]#boot2# client. The BTX server acts as a kernel, and executes in protected mode in the most privileged level. In contrast, the BTX clients ([.filename]#boot2#, for example), execute in user mode. We will see how this is accomplished in the next section. The code after the call to `nread` locates the beginning of [.filename]#boot2# in the memory buffer, and copies it to memory address `0xc000`. This is because the BTX server arranges [.filename]#boot2# to execute in a segment starting at `0xa000`. We explore this in detail in the following section.
+Starting at address `0x9000` is the beginning of the BTX server, and immediately following is the [.filename]#boot2# client.
+The BTX server acts as a kernel, and executes in protected mode in the most privileged level.
+In contrast, the BTX clients ([.filename]#boot2#, for example), execute in user mode.
+We will see how this is accomplished in the next section.
+The code after the call to `nread` locates the beginning of [.filename]#boot2# in the memory buffer, and copies it to memory address `0xc000`.
+This is because the BTX server arranges [.filename]#boot2# to execute in a segment starting at `0xa000`.
+We explore this in detail in the following section.
-The last code block of [.filename]#boot1# enables access to memory above 1MB footnote:[This is necessary for legacy reasons. Interested readers should see .] and concludes with a jump to the starting point of the BTX server:
+The last code block of [.filename]#boot1# enables access to memory above 1MB footnote:[This is necessary for legacy reasons.
+Interested readers should see .] and concludes with a jump to the starting point of the BTX server:
[.programlisting]
....
@@ -550,19 +743,27 @@ seta20.3:
jmp 0x9010 # Start BTX
....
-.[.filename]#sys/boot/i386/boot2/boot1.S# [[boot-boot1-seta20]]
+.[.filename]#stand/i386/boot2/boot1.S# [[boot-boot1-seta20]]
Note that right before the jump, interrupts are enabled.
[[btx-server]]
== The BTX Server
-Next in our boot sequence is the BTX Server. Let us quickly remember how we got here:
+Next in our boot sequence is the BTX Server.
+Let us quickly remember how we got here:
* The BIOS loads the absolute sector one (the MBR, or [.filename]#boot0#), to address `0x7c00` and jumps there.
-* [.filename]#boot0# relocates itself to `0x600`, the address it was linked to execute, and jumps over there. It then reads the first sector of the FreeBSD slice (which consists of [.filename]#boot1#) into address `0x7c00` and jumps over there.
-* [.filename]#boot1# loads the first 16 sectors of the FreeBSD slice into address `0x8c00`. This 16 sectors, or 8192 bytes, is the whole file [.filename]#boot#. The file is a concatenation of [.filename]#boot1# and [.filename]#boot2#. [.filename]#boot2#, in turn, contains the BTX server and the [.filename]#boot2# client. Finally, a jump is made to address `0x9010`, the entry point of the BTX server.
-
-Before studying the BTX Server in detail, let us further review how the single, all-in-one [.filename]#boot# file is created. The way [.filename]#boot# is built is defined in its [.filename]#Makefile# ([.filename]#/usr/src/sys/boot/i386/boot2/Makefile#). Let us look at the rule that creates the [.filename]#boot# file:
+* [.filename]#boot0# relocates itself to `0x600`, the address it was linked to execute, and jumps over there.
+It then reads the first sector of the FreeBSD slice (which consists of [.filename]#boot1#) into address `0x7c00` and jumps over there.
+* [.filename]#boot1# loads the first 16 sectors of the FreeBSD slice into address `0x8c00`.
+This 16 sectors, or 8192 bytes, is the whole file [.filename]#boot#.
+The file is a concatenation of [.filename]#boot1# and [.filename]#boot2#.
+[.filename]#boot2#, in turn, contains the BTX server and the [.filename]#boot2# client.
+Finally, a jump is made to address `0x9010`, the entry point of the BTX server.
+
+Before studying the BTX Server in detail, let us further review how the single, all-in-one [.filename]#boot# file is created.
+The way [.filename]#boot# is built is defined in its [.filename]#Makefile# ([.filename]#stand/i386/boot2/Makefile#).
+Let us look at the rule that creates the [.filename]#boot# file:
[.programlisting]
....
@@ -570,50 +771,50 @@ Before studying the BTX Server in detail, let us further review how the single,
cat boot1 boot2 > boot
....
-.[.filename]#sys/boot/i386/boot2/Makefile# [[boot-boot1-make-boot]]
-This tells us that [.filename]#boot1# and [.filename]#boot2# are needed, and the rule simply concatenates them to produce a single file called [.filename]#boot#. The rules for creating [.filename]#boot1# are also quite simple:
+.[.filename]#stand/i386/boot2/Makefile# [[boot-boot1-make-boot]]
+This tells us that [.filename]#boot1# and [.filename]#boot2# are needed, and the rule simply concatenates them to produce a single file called [.filename]#boot#.
+The rules for creating [.filename]#boot1# are also quite simple:
[.programlisting]
....
boot1: boot1.out
- objcopy -S -O binary boot1.out boot1
+ ${OBJCOPY} -S -O binary boot1.out ${.TARGET}
boot1.out: boot1.o
- ld -e start -Ttext 0x7c00 -o boot1.out boot1.o
+ ${LD} ${LD_FLAGS} -e start --defsym ORG=${ORG1} -T ${LDSCRIPT} -o ${.TARGET} boot1.o
....
-.[.filename]#sys/boot/i386/boot2/Makefile# [[boot-boot1-make-boot1]]
-To apply the rule for creating [.filename]#boot1#, [.filename]#boot1.out# must be resolved. This, in turn, depends on the existence of [.filename]#boot1.o#. This last file is simply the result of assembling our familiar [.filename]#boot1.S#, without linking. Now, the rule for creating [.filename]#boot1.out# is applied. This tells us that [.filename]#boot1.o# should be linked with `start` as its entry point, and starting at address `0x7c00`. Finally, [.filename]#boot1# is created from [.filename]#boot1.out# applying the appropriate rule. This rule is the [.filename]#objcopy# command applied to [.filename]#boot1.out#. Note the flags passed to [.filename]#objcopy#: `-S` tells it to strip all relocation and symbolic information; `-O binary` indicates the output format, that is, a simple, unformatted binary file.
+.[.filename]#stand/i386/boot2/Makefile# [[boot-boot1-make-boot1]]
+To apply the rule for creating [.filename]#boot1#, [.filename]#boot1.out# must be resolved.
+This, in turn, depends on the existence of [.filename]#boot1.o#.
+This last file is simply the result of assembling our familiar [.filename]#boot1.S#, without linking.
+Now, the rule for creating [.filename]#boot1.out# is applied.
+This tells us that [.filename]#boot1.o# should be linked with `start` as its entry point, and starting at address `0x7c00`.
+Finally, [.filename]#boot1# is created from [.filename]#boot1.out# applying the appropriate rule.
+This rule is the [.filename]#objcopy# command applied to [.filename]#boot1.out#.
+Note the flags passed to [.filename]#objcopy#: `-S` tells it to strip all relocation and symbolic information; `-O binary` indicates the output format, that is, a simple, unformatted binary file.
Having [.filename]#boot1#, let us take a look at how [.filename]#boot2# is constructed:
[.programlisting]
....
boot2: boot2.ld
- @set -- `ls -l boot2.ld`; x=$$((7680-$$5)); \
+ @set -- `ls -l ${.ALLSRC}`; x=$$((${BOOT2SIZE}-$$5)); \
echo "$$x bytes available"; test $$x -ge 0
- dd if=boot2.ld of=boot2 obs=7680 conv=osync
+ ${DD} if=${.ALLSRC} of=${.TARGET} bs=${BOOT2SIZE} conv=sync
- boot2.ld: boot2.ldr boot2.bin ../btx/btx/btx
- btxld -v -E 0x2000 -f bin -b ../btx/btx/btx -l boot2.ldr \
- -o boot2.ld -P 1 boot2.bin
+ boot2.ld: boot2.ldr boot2.bin ${BTXKERN}
+ btxld -v -E ${ORG2} -f bin -b ${BTXKERN} -l boot2.ldr \
+ -o ${.TARGET} -P 1 boot2.bin
boot2.ldr:
- dd if=/dev/zero of=boot2.ldr bs=512 count=1
+ ${DD} if=/dev/zero of=${.TARGET} bs=512 count=1
boot2.bin: boot2.out
- objcopy -S -O binary boot2.out boot2.bin
-
- boot2.out: ../btx/lib/crt0.o boot2.o sio.o
- ld -Ttext 0x2000 -o boot2.out
-
- boot2.o: boot2.s
- ${CC} ${ACFLAGS} -c boot2.s
+ ${OBJCOPY} -S -O binary boot2.out ${.TARGET}
- boot2.s: boot2.c boot2.h ${.CURDIR}/../../common/ufsread.c
- ${CC} ${CFLAGS} -S -o boot2.s.tmp ${.CURDIR}/boot2.c
- sed -e '/align/d' -e '/nop/d' "MISSING" boot2.s.tmp > boot2.s
- rm -f boot2.s.tmp
+ boot2.out: ${BTXCRT} boot2.o sio.o ashldi3.o
+ ${LD} ${LD_FLAGS} --defsym ORG=${ORG2} -T ${LDSCRIPT} -o ${.TARGET} ${.ALLSRC}
boot2.h: boot1.out
${NM} -t d ${.ALLSRC} | awk '/([0-9])+ T xread/ \
@@ -623,45 +824,75 @@ Having [.filename]#boot1#, let us take a look at how [.filename]#boot2# is const
REL1=`printf "%d" ${REL1}` > ${.TARGET}
....
-.[.filename]#sys/boot/i386/boot2/Makefile# [[boot-boot1-make-boot2]]
-The mechanism for building [.filename]#boot2# is far more elaborate. Let us point out the most relevant facts. The dependency list is as follows:
+.[.filename]#stand/i386/boot2/Makefile# [[boot-boot1-make-boot2]]
+The mechanism for building [.filename]#boot2# is far more elaborate.
+Let us point out the most relevant facts.
+The dependency list is as follows:
[.programlisting]
....
boot2: boot2.ld
- boot2.ld: boot2.ldr boot2.bin ${BTXDIR}/btx/btx
+ boot2.ld: boot2.ldr boot2.bin ${BTXDIR}
boot2.bin: boot2.out
- boot2.out: ${BTXDIR}/lib/crt0.o boot2.o sio.o
- boot2.o: boot2.s
- boot2.s: boot2.c boot2.h ${.CURDIR}/../../common/ufsread.c
+ boot2.out: ${BTXDIR} boot2.o sio.o ashldi3.o
boot2.h: boot1.out
....
-.[.filename]#sys/boot/i386/boot2/Makefile# [[boot-boot1-make-boot2-more]]
-Note that initially there is no header file [.filename]#boot2.h#, but its creation depends on [.filename]#boot1.out#, which we already have. The rule for its creation is a bit terse, but the important thing is that the output, [.filename]#boot2.h#, is something like this:
+.[.filename]#stand/i386/boot2/Makefile# [[boot-boot1-make-boot2-more]]
+Note that initially there is no header file [.filename]#boot2.h#, but its creation depends on [.filename]#boot1.out#, which we already have.
+The rule for its creation is a bit terse, but the important thing is that the output, [.filename]#boot2.h#, is something like this:
[.programlisting]
....
#define XREADORG 0x725
....
-.[.filename]#sys/boot/i386/boot2/boot2.h# [[boot-boot1-make-boot2h]]
-Recall that [.filename]#boot1# was relocated (i.e., copied from `0x7c00` to `0x700`). This relocation will now make sense, because as we will see, the BTX server reclaims some memory, including the space where [.filename]#boot1# was originally loaded. However, the BTX server needs access to [.filename]#boot1#'s `xread` function; this function, according to the output of [.filename]#boot2.h#, is at location `0x725`. Indeed, the BTX server uses the `xread` function from [.filename]#boot1#'s relocated code. This function is now accessible from within the [.filename]#boot2# client.
-
-We next build [.filename]#boot2.s# from files [.filename]#boot2.h#, [.filename]#boot2.c# and [.filename]#/usr/src/sys/boot/common/ufsread.c#. The rule for this is to compile the code in [.filename]#boot2.c# (which includes [.filename]#boot2.h# and [.filename]#ufsread.c#) into assembly code. Having [.filename]#boot2.s#, the next rule assembles [.filename]#boot2.s#, creating the object file [.filename]#boot2.o#. The next rule directs the linker to link various files ([.filename]#crt0.o#, [.filename]#boot2.o# and [.filename]#sio.o#). Note that the output file, [.filename]#boot2.out#, is linked to execute at address `0x2000`. Recall that [.filename]#boot2# will be executed in user mode, within a special user segment set up by the BTX server. This segment starts at `0xa000`. Also, remember that the [.filename]#boot2# portion of [.filename]#boot# was copied to address `0xc000`, that is, offset `0x2000` from the start of the user segment, so [.filename]#boot2# will work properly when we transfer control to it. Next, [.filename]#boot2.bin# is created from [.filename]#boot2.out# by stripping its symbols and format information; boot2.bin is a _raw_ binary. Now, note that a file [.filename]#boot2.ldr# is created as a 512-byte file full of zeros. This space is reserved for the bsdlabel.
-
-Now that we have files [.filename]#boot1#, [.filename]#boot2.bin# and [.filename]#boot2.ldr#, only the BTX server is missing before creating the all-in-one [.filename]#boot# file. The BTX server is located in [.filename]#/usr/src/sys/boot/i386/btx/btx#; it has its own [.filename]#Makefile# with its own set of rules for building. The important thing to notice is that it is also compiled as a _raw_ binary, and that it is linked to execute at address `0x9000`. The details can be found in [.filename]#/usr/src/sys/boot/i386/btx/btx/Makefile#.
-
-Having the files that comprise the [.filename]#boot# program, the final step is to _merge_ them. This is done by a special program called [.filename]#btxld# (source located in [.filename]#/usr/src/usr.sbin/btxld#). Some arguments to this program include the name of the output file ([.filename]#boot#), its entry point (`0x2000`) and its file format (raw binary). The various files are finally merged by this utility into the file [.filename]#boot#, which consists of [.filename]#boot1#, [.filename]#boot2#, the `bsdlabel` and the BTX server. This file, which takes exactly 16 sectors, or 8192 bytes, is what is actually written to the beginning of the FreeBSD slice during installation. Let us now proceed to study the BTX server program.
-
-The BTX server prepares a simple environment and switches from 16-bit real mode to 32-bit protected mode, right before passing control to the client. This includes initializing and updating the following data structures:
-
-* Modifies the `Interrupt Vector Table (IVT)`. The IVT provides exception and interrupt handlers for Real-Mode code.
-* The `Interrupt Descriptor Table (IDT)` is created. Entries are provided for processor exceptions, hardware interrupts, two system calls and V86 interface. The IDT provides exception and interrupt handlers for Protected-Mode code.
-* A `Task-State Segment (TSS)` is created. This is necessary because the processor works in the _least_ privileged level when executing the client ([.filename]#boot2#), but in the _most_ privileged level when executing the BTX server.
-* The GDT (Global Descriptor Table) is set up. Entries (descriptors) are provided for supervisor code and data, user code and data, and real-mode code and data. footnote:[Real-mode code and data are necessary when switching back to real mode from protected mode, as suggested by the Intel manuals.]
-
-Let us now start studying the actual implementation. Recall that [.filename]#boot1# made a jump to address `0x9010`, the BTX server's entry point. Before studying program execution there, note that the BTX server has a special header at address range `0x9000-0x900f`, right before its entry point. This header is defined as follows:
+.[.filename]#stand/i386/boot2/boot2.h# [[boot-boot1-make-boot2h]]
+Recall that [.filename]#boot1# was relocated (i.e., copied from `0x7c00` to `0x700`).
+This relocation will now make sense, because as we will see, the BTX server reclaims some memory, including the space where [.filename]#boot1# was originally loaded.
+However, the BTX server needs access to [.filename]#boot1#'s `xread` function; this function, according to the output of [.filename]#boot2.h#, is at location `0x725`.
+Indeed, the BTX server uses the `xread` function from [.filename]#boot1#'s relocated code.
+This function is now accessible from within the [.filename]#boot2# client.
+
+The next rule directs the linker to link various files ([.filename]#ashldi3.o#, [.filename]#boot2.o# and [.filename]#sio.o#).
+Note that the output file, [.filename]#boot2.out#, is linked to execute at address `0x2000` (${ORG2}).
+Recall that [.filename]#boot2# will be executed in user mode, within a special user segment set up by the BTX server.
+This segment starts at `0xa000`.
+Also, remember that the [.filename]#boot2# portion of [.filename]#boot# was copied to address `0xc000`, that is, offset `0x2000` from the start of the user segment, so [.filename]#boot2# will work properly when we transfer control to it.
+Next, [.filename]#boot2.bin# is created from [.filename]#boot2.out# by stripping its symbols and format information; boot2.bin is a _raw_ binary.
+Now, note that a file [.filename]#boot2.ldr# is created as a 512-byte file full of zeros.
+This space is reserved for the bsdlabel.
+
+Now that we have files [.filename]#boot1#, [.filename]#boot2.bin# and [.filename]#boot2.ldr#, only the BTX server is missing before creating the all-in-one [.filename]#boot# file.
+The BTX server is located in [.filename]#stand/i386/btx/btx#; it has its own [.filename]#Makefile# with its own set of rules for building.
+The important thing to notice is that it is also compiled as a _raw_ binary, and that it is linked to execute at address `0x9000`.
+The details can be found in [.filename]#stand/i386/btx/btx/Makefile#.
+
+Having the files that comprise the [.filename]#boot# program, the final step is to _merge_ them.
+This is done by a special program called [.filename]#btxld# (source located in [.filename]#/usr/src/usr.sbin/btxld#).
+Some arguments to this program include the name of the output file ([.filename]#boot#), its entry point (`0x2000`) and its file format (raw binary).
+The various files are finally merged by this utility into the file [.filename]#boot#, which consists of [.filename]#boot1#, [.filename]#boot2#, the `bsdlabel` and the BTX server.
+This file, which takes exactly 16 sectors, or 8192 bytes, is what is actually written to the beginning of the FreeBSD slice during installation.
+Let us now proceed to study the BTX server program.
+
+The BTX server prepares a simple environment and switches from 16-bit real mode to 32-bit protected mode, right before passing control to the client.
+This includes initializing and updating the following data structures:
+
+* Modifies the `Interrupt Vector Table (IVT)`.
+The IVT provides exception and interrupt handlers for Real-Mode code.
+* The `Interrupt Descriptor Table (IDT)` is created.
+Entries are provided for processor exceptions, hardware interrupts, two system calls and V86 interface.
+The IDT provides exception and interrupt handlers for Protected-Mode code.
+* A `Task-State Segment (TSS)` is created.
+This is necessary because the processor works in the _least_ privileged level when executing the client ([.filename]#boot2#), but in the _most_ privileged level when executing the BTX server.
+* The GDT (Global Descriptor Table) is set up.
+Entries (descriptors) are provided for supervisor code and data, user code and data, and real-mode code and data.
+footnote:[Real-mode code and data are necessary when switching back to real mode from protected mode, as suggested by the Intel manuals.]
+
+Let us now start studying the actual implementation.
+Recall that [.filename]#boot1# made a jump to address `0x9010`, the BTX server's entry point.
+Before studying program execution there, note that the BTX server has a special header at address range `0x9000-0x900f`, right before its entry point.
+This header is defined as follows:
[.programlisting]
....
@@ -680,8 +911,11 @@ btx_hdr: .byte 0xeb # Machine ID
.long 0x0 # Entry address
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-header]]
-Note the first two bytes are `0xeb` and `0xe`. In the IA-32 architecture, these two bytes are interpreted as a relative jump past the header into the entry point, so in theory, [.filename]#boot1# could jump here (address `0x9000`) instead of address `0x9010`. Note that the last field in the BTX header is a pointer to the client's ([.filename]#boot2#) entry point. This field is patched at link time.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-header]]
+Note the first two bytes are `0xeb` and `0xe`.
+In the IA-32 architecture, these two bytes are interpreted as a relative jump past the header into the entry point, so in theory, [.filename]#boot1# could jump here (address `0x9000`) instead of address `0x9010`.
+Note that the last field in the BTX header is a pointer to the client's ([.filename]#boot2#) entry pointb2.
+This field is patched at link time.
Immediately following the header is the BTX server's entry point:
@@ -693,33 +927,43 @@ Immediately following the header is the BTX server's entry point:
init: cli # Disable interrupts
xor %ax,%ax # Zero/segment
mov %ax,%ss # Set up
- mov $0x1800,%sp # stack
+ mov $MEM_ESP0,%sp # stack
mov %ax,%es # Address
mov %ax,%ds # data
pushl $0x2 # Clear
popfl # flags
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-init]]
-This code disables interrupts, sets up a working stack (starting at address `0x1800`) and clears the flags in the EFLAGS register. Note that the `popfl` instruction pops out a doubleword (4 bytes) from the stack and places it in the EFLAGS register. As the value actually popped is `2`, the EFLAGS register is effectively cleared (IA-32 requires that bit 2 of the EFLAGS register always be 1).
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-init]]
+This code disables interrupts, sets up a working stack (starting at address `0x1800`) and clears the flags in the EFLAGS register.
+Note that the `popfl` instruction pops out a doubleword (4 bytes) from the stack and places it in the EFLAGS register.
+As the value actually popped is `2`, the EFLAGS register is effectively cleared (IA-32 requires that bit 2 of the EFLAGS register always be 1).
-Our next code block clears (sets to `0`) the memory range `0x5e00-0x8fff`. This range is where the various data structures will be created:
+Our next code block clears (sets to `0`) the memory range `0x5e00-0x8fff`.
+This range is where the various data structures will be created:
[.programlisting]
....
/*
* Initialize memory.
*/
- mov $0x5e00,%di # Memory to initialize
- mov $(0x9000-0x5e00)/2,%cx # Words to zero
+ mov $MEM_IDT,%di # Memory to initialize
+ mov $(MEM_ORG-MEM_IDT)/2,%cx # Words to zero
rep # Zero-fill
stosw # memory
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-clear-mem]]
-Recall that [.filename]#boot1# was originally loaded to address `0x7c00`, so, with this memory initialization, that copy effectively disappeared. However, also recall that [.filename]#boot1# was relocated to `0x700`, so _that_ copy is still in memory, and the BTX server will make use of it.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-clear-mem]]
+Recall that [.filename]#boot1# was originally loaded to address `0x7c00`, so, with this memory initialization, that copy effectively disappeared.
+However, also recall that [.filename]#boot1# was relocated to `0x700`, so _that_ copy is still in memory, and the BTX server will make use of it.
-Next, the real-mode IVT (Interrupt Vector Table is updated. The IVT is an array of segment/offset pairs for exception and interrupt handlers. The BIOS normally maps hardware interrupts to interrupt vectors `0x8` to `0xf` and `0x70` to `0x77` but, as will be seen, the 8259A Programmable Interrupt Controller, the chip controlling the actual mapping of hardware interrupts to interrupt vectors, is programmed to remap these interrupt vectors from `0x8-0xf` to `0x20-0x27` and from `0x70-0x77` to `0x28-0x2f`. Thus, interrupt handlers are provided for interrupt vectors `0x20-0x2f`. The reason the BIOS-provided handlers are not used directly is because they work in 16-bit real mode, but not 32-bit protected mode. Processor mode will be switched to 32-bit protected mode shortly. However, the BTX server sets up a mechanism to effectively use the handlers provided by the BIOS:
+Next, the real-mode IVT (Interrupt Vector Table is updated.
+The IVT is an array of segment/offset pairs for exception and interrupt handlers.
+The BIOS normally maps hardware interrupts to interrupt vectors `0x8` to `0xf` and `0x70` to `0x77` but, as will be seen, the 8259A Programmable Interrupt Controller, the chip controlling the actual mapping of hardware interrupts to interrupt vectors, is programmed to remap these interrupt vectors from `0x8-0xf` to `0x20-0x27` and from `0x70-0x77` to `0x28-0x2f`.
+Thus, interrupt handlers are provided for interrupt vectors `0x20-0x2f`.
+The reason the BIOS-provided handlers are not used directly is because they work in 16-bit real mode, but not 32-bit protected mode.
+Processor mode will be switched to 32-bit protected mode shortly.
+However, the BTX server sets up a mechanism to effectively use the handlers provided by the BIOS:
[.programlisting]
....
@@ -737,15 +981,18 @@ init.0: mov %bx,(%di) # Store IP
loop init.0 # Next IRQ
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-ivt]]
-The next block creates the IDT (Interrupt Descriptor Table). The IDT is analogous, in protected mode, to the IVT in real mode. That is, the IDT describes the various exception and interrupt handlers used when the processor is executing in protected mode. In essence, it also consists of an array of segment/offset pairs, although the structure is somewhat more complex, because segments in protected mode are different than in real mode, and various protection mechanisms apply:
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-ivt]]
+The next block creates the IDT (Interrupt Descriptor Table).
+The IDT is analogous, in protected mode, to the IVT in real mode.
+That is, the IDT describes the various exception and interrupt handlers used when the processor is executing in protected mode.
+In essence, it also consists of an array of segment/offset pairs, although the structure is somewhat more complex, because segments in protected mode are different than in real mode, and various protection mechanisms apply:
[.programlisting]
....
/*
* Create IDT.
*/
- mov $0x5e00,%di # IDT's address
+ mov $MEM_IDT,%di # IDT's address
mov $idtctl,%si # Control string
init.1: lodsb # Get entry
cbw # count
@@ -768,10 +1015,19 @@ init.3: lea 0x8(%di),%di # Next entry
jmp init.1 # Continue
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-idt]]
-Each entry in the `IDT` is 8 bytes long. Besides the segment/offset information, they also describe the segment type, privilege level, and whether the segment is present in memory or not. The construction is such that interrupt vectors from `0` to `0xf` (exceptions) are handled by function `intx00`; vector `0x10` (also an exception) is handled by `intx10`; hardware interrupts, which are later configured to start at interrupt vector `0x20` all the way to interrupt vector `0x2f`, are handled by function `intx20`. Lastly, interrupt vector `0x30`, which is used for system calls, is handled by `intx30`, and vectors `0x31` and `0x32` are handled by `intx31`. It must be noted that only descriptors for interrupt vectors `0x30`, `0x31` and `0x32` are given privilege level 3, the same privilege level as the [.filename]#boot2# client, which means the client can execute a software-generated interrupt to this vectors through the `int` instruction without failing (this is the way [.filename]#boot2# use the services provided by the BTX server). Also, note that _only_ software-generated interrupts are protected from code executing in lesser privilege levels. Hardware-generated interrupts and processor-generated exceptions are _always_ handled adequately, regardless of the actual privileges involved.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-idt]]
+Each entry in the `IDT` is 8 bytes long.
+Besides the segment/offset information, they also describe the segment type, privilege level, and whether the segment is present in memory or not.
+The construction is such that interrupt vectors from `0` to `0xf` (exceptions) are handled by function `intx00`; vector `0x10` (also an exception) is handled by `intx10`; hardware interrupts, which are later configured to start at interrupt vector `0x20` all the way to interrupt vector `0x2f`, are handled by function `intx20`.
+Lastly, interrupt vector `0x30`, which is used for system calls, is handled by `intx30`, and vectors `0x31` and `0x32` are handled by `intx31`.
+It must be noted that only descriptors for interrupt vectors `0x30`, `0x31` and `0x32` are given privilege level 3, the same privilege level as the [.filename]#boot2# client, which means the client can execute a software-generated interrupt to this vectors through the `int` instruction without failing (this is the way [.filename]#boot2# use the services provided by the BTX server).
+Also, note that _only_ software-generated interrupts are protected from code executing in lesser privilege levels.
+Hardware-generated interrupts and processor-generated exceptions are _always_ handled adequately, regardless of the actual privileges involved.
-The next step is to initialize the TSS (Task-State Segment). The TSS is a hardware feature that helps the operating system or executive software implement multitasking functionality through process abstraction. The IA-32 architecture demands the creation and use of _at least_ one TSS if multitasking facilities are used or different privilege levels are defined. Since the [.filename]#boot2# client is executed in privilege level 3, but the BTX server runs in privilege level 0, a TSS must be defined:
+The next step is to initialize the TSS (Task-State Segment).
+The TSS is a hardware feature that helps the operating system or executive software implement multitasking functionality through process abstraction.
+The IA-32 architecture demands the creation and use of _at least_ one TSS if multitasking facilities are used or different privilege levels are defined.
+Since the [.filename]#boot2# client is executed in privilege level 3, but the BTX server runs in privilege level 0, a TSS must be defined:
[.programlisting]
....
@@ -783,10 +1039,13 @@ init.4: movb $_ESP0H,TSS_ESP0+1(%di) # Set ESP0
movb $_TSSIO,TSS_MAP(%di) # Set I/O bit map base
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-tss]]
-Note that a value is given for the Privilege Level 0 stack pointer and stack segment in the TSS. This is needed because, if an interrupt or exception is received while executing [.filename]#boot2# in Privilege Level 3, a change to Privilege Level 0 is automatically performed by the processor, so a new working stack is needed. Finally, the I/O Map Base Address field of the TSS is given a value, which is a 16-bit offset from the beginning of the TSS to the I/O Permission Bitmap and the Interrupt Redirection Bitmap.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-tss]]
+Note that a value is given for the Privilege Level 0 stack pointer and stack segment in the TSS.
+This is needed because, if an interrupt or exception is received while executing [.filename]#boot2# in Privilege Level 3, a change to Privilege Level 0 is automatically performed by the processor, so a new working stack is needed.
+Finally, the I/O Map Base Address field of the TSS is given a value, which is a 16-bit offset from the beginning of the TSS to the I/O Permission Bitmap and the Interrupt Redirection Bitmap.
-After the IDT and TSS are created, the processor is ready to switch to protected mode. This is done in the next block:
+After the IDT and TSS are created, the processor is ready to switch to protected mode.
+This is done in the next block:
[.programlisting]
....
@@ -807,8 +1066,19 @@ init.8: xorl %ecx,%ecx # Zero
movw %cx,%ss # stack
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-prot]]
-First, a call is made to `setpic` to program the 8259A PIC (Programmable Interrupt Controller). This chip is connected to multiple hardware interrupt sources. Upon receiving an interrupt from a device, it signals the processor with the appropriate interrupt vector. This can be customized so that specific interrupts are associated with specific interrupt vectors, as explained before. Next, the IDTR (Interrupt Descriptor Table Register) and GDTR (Global Descriptor Table Register) are loaded with the instructions `lidt` and `lgdt`, respectively. These registers are loaded with the base address and limit address for the IDT and GDT. The following three instructions set the Protection Enable (PE) bit of the `%cr0` register. This effectively switches the processor to 32-bit protected mode. Next, a long jump is made to `init.8` using segment selector SEL_SCODE, which selects the Supervisor Code Segment. The processor is effectively executing in CPL 0, the most privileged level, after this jump. Finally, the Supervisor Data Segment is selected for the stack by assigning the segment selector SEL_SDATA to the `%ss` register. This data segment also has a privilege level of `0`.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-prot]]
+First, a call is made to `setpic` to program the 8259A PIC (Programmable Interrupt Controller).
+This chip is connected to multiple hardware interrupt sources.
+Upon receiving an interrupt from a device, it signals the processor with the appropriate interrupt vector.
+This can be customized so that specific interrupts are associated with specific interrupt vectors, as explained before.
+Next, the IDTR (Interrupt Descriptor Table Register) and GDTR (Global Descriptor Table Register) are loaded with the instructions `lidt` and `lgdt`, respectively.
+These registers are loaded with the base address and limit address for the IDT and GDT.
+The following three instructions set the Protection Enable (PE) bit of the `%cr0` register.
+This effectively switches the processor to 32-bit protected mode.
+Next, a long jump is made to `init.8` using segment selector SEL_SCODE, which selects the Supervisor Code Segment.
+The processor is effectively executing in CPL 0, the most privileged level, after this jump.
+Finally, the Supervisor Data Segment is selected for the stack by assigning the segment selector SEL_SDATA to the `%ss` register.
+This data segment also has a privilege level of `0`.
Our last code block is responsible for loading the TR (Task Register) with the segment selector for the TSS we created earlier, and setting the User Mode environment before passing execution control to the [.filename]#boot2# client.
@@ -819,7 +1089,7 @@ Our last code block is responsible for loading the TR (Task Register) with the s
*/
movb $SEL_TSS,%cl # Set task
ltr %cx # register
- movl $0xa000,%edx # User base address
+ movl $MEM_USR,%edx # User base address
movzwl %ss:BDA_MEM,%eax # Get free memory
shll $0xa,%eax # To bytes
subl $ARGSPACE,%eax # Less arg space
@@ -838,6 +1108,9 @@ Our last code block is responsible for loading the TR (Task Register) with the s
movb $0x7,%cl # Set remaining
init.9: push $0x0 # general
loop init.9 # registers
+#ifdef BTX_SERIAL
+ call sio_init # setup the serial console
+#endif
popa # and initialize
popl %es # Initialize
popl %ds # user
@@ -846,15 +1119,43 @@ init.9: push $0x0 # general
iret # To user mode
....
-.[.filename]#sys/boot/i386/btx/btx/btx.S# [[btx-end]]
-Note that the client's environment include a stack segment selector and stack pointer (registers `%ss` and `%esp`). Indeed, once the TR is loaded with the appropriate stack segment selector (instruction `ltr`), the stack pointer is calculated and pushed onto the stack along with the stack's segment selector. Next, the value `0x202` is pushed onto the stack; it is the value that the EFLAGS will get when control is passed to the client. Also, the User Mode code segment selector and the client's entry point are pushed. Recall that this entry point is patched in the BTX header at link time. Finally, segment selectors (stored in register `%ecx`) for the segment registers `%gs, %fs, %ds and %es` are pushed onto the stack, along with the value at `%edx` (`0xa000`). Keep in mind the various values that have been pushed onto the stack (they will be popped out shortly). Next, values for the remaining general purpose registers are also pushed onto the stack (note the `loop` that pushes the value `0` seven times). Now, values will be started to be popped out of the stack. First, the `popa` instruction pops out of the stack the latest seven values pushed. They are stored in the general purpose registers in order `%edi, %esi, %ebp, %ebx, %edx, %ecx, %eax`. Then, the various segment selectors pushed are popped into the various segment registers. Five values still remain on the stack. They are popped when the `iret` instruction is executed. This instruction first pops the value that was pushed from the BTX header. This value is a pointer to [.filename]#boot2#'s entry point. It is placed in the register `%eip`, the instruction pointer register. Next, the segment selector for the User Code Segment is popped and copied to register `%cs`. Remember that this segment's privilege level is 3, the least privileged level. This means that we must provide values for the stack of this privilege level. This is why the processor, besides further popping the value for the EFLAGS register, does two more pops out of the stack. These values go to the stack pointer (`%esp`) and the stack segment (`%ss`). Now, execution continues at ``boot0``'s entry point.
-
-It is important to note how the User Code Segment is defined. This segment's _base address_ is set to `0xa000`. This means that code memory addresses are _relative_ to address 0xa000; if code being executed is fetched from address `0x2000`, the _actual_ memory addressed is `0xa000+0x2000=0xc000`.
+.[.filename]#stand/i386/btx/btx/btx.S# [[btx-end]]
+Note that the client's environment include a stack segment selector and stack pointer (registers `%ss` and `%esp`).
+Indeed, once the TR is loaded with the appropriate stack segment selector (instruction `ltr`), the stack pointer is calculated and pushed onto the stack along with the stack's segment selector.
+Next, the value `0x202` is pushed onto the stack; it is the value that the EFLAGS will get when control is passed to the client.
+Also, the User Mode code segment selector and the client's entry point are pushed.
+Recall that this entry point is patched in the BTX header at link time.
+Finally, segment selectors (stored in register `%ecx`) for the segment registers `%gs, %fs, %ds and %es` are pushed onto the stack, along with the value at `%edx` (`0xa000`).
+Keep in mind the various values that have been pushed onto the stack (they will be popped out shortly).
+Next, values for the remaining general purpose registers are also pushed onto the stack (note the `loop` that pushes the value `0` seven times).
+Now, values will be started to be popped out of the stack.
+First, the `popa` instruction pops out of the stack the latest seven values pushed.
+They are stored in the general purpose registers in order `%edi, %esi, %ebp, %ebx, %edx, %ecx, %eax`.
+Then, the various segment selectors pushed are popped into the various segment registers.
+Five values still remain on the stack.
+They are popped when the `iret` instruction is executed.
+This instruction first pops the value that was pushed from the BTX header.
+This value is a pointer to [.filename]#boot2#'s entry point.
+It is placed in the register `%eip`, the instruction pointer register.
+Next, the segment selector for the User Code Segment is popped and copied to register `%cs`.
+Remember that this segment's privilege level is 3, the least privileged level.
+This means that we must provide values for the stack of this privilege level.
+This is why the processor, besides further popping the value for the EFLAGS register, does two more pops out of the stack.
+These values go to the stack pointer (`%esp`) and the stack segment (`%ss`).
+Now, execution continues at ``boot0``'s entry point.
+
+It is important to note how the User Code Segment is defined.
+This segment's _base address_ is set to `0xa000`.
+This means that code memory addresses are _relative_ to address 0xa000; if code being executed is fetched from address `0x2000`, the _actual_ memory addressed is `0xa000+0x2000=0xc000`.
[[boot2]]
== boot2 Stage
-`boot2` defines an important structure, `struct bootinfo`. This structure is initialized by `boot2` and passed to the loader, and then further to the kernel. Some nodes of this structures are set by `boot2`, the rest by the loader. This structure, among other information, contains the kernel filename, BIOS harddisk geometry, BIOS drive number for boot device, physical memory available, `envp` pointer etc. The definition for it is:
+`boot2` defines an important structure, `struct bootinfo`.
+This structure is initialized by `boot2` and passed to the loader, and then further to the kernel.
+Some nodes of this structures are set by `boot2`, the rest by the loader.
+This structure, among other information, contains the kernel filename, BIOS harddisk geometry, BIOS drive number for boot device, physical memory available, `envp` pointer etc.
+The definition for it is:
[.programlisting]
....
@@ -882,44 +1183,58 @@ struct bootinfo {
};
....
-`boot2` enters into an infinite loop waiting for user input, then calls `load()`. If the user does not press anything, the loop breaks by a timeout, so `load()` will load the default file ([.filename]#/boot/loader#). Functions `ino_t lookup(char *filename)` and `int xfsread(ino_t inode, void *buf, size_t nbyte)` are used to read the content of a file into memory. [.filename]#/boot/loader# is an ELF binary, but where the ELF header is prepended with [.filename]#a.out#'s `struct exec` structure. `load()` scans the loader's ELF header, loading the content of [.filename]#/boot/loader# into memory, and passing the execution to the loader's entry:
+`boot2` enters into an infinite loop waiting for user input, then calls `load()`.
+If the user does not press anything, the loop breaks by a timeout, so `load()` will load the default file ([.filename]#/boot/loader#).
+Functions `ino_t lookup(char *filename)` and `int xfsread(ino_t inode, void *buf, size_t nbyte)` are used to read the content of a file into memory.
+[.filename]#/boot/loader# is an ELF binary, but where the ELF header is prepended with [.filename]#a.out#'s `struct exec` structure.
+`load()` scans the loader's ELF header, loading the content of [.filename]#/boot/loader# into memory, and passing the execution to the loader's entry:
[.programlisting]
....
-sys/boot/i386/boot2/boot2.c:
+stand/i386/boot2/boot2.c:
__exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),
- MAKEBOOTDEV(dev_maj[dsk.type], 0, dsk.slice, dsk.unit, dsk.part),
+ MAKEBOOTDEV(dev_maj[dsk.type], dsk.slice, dsk.unit, dsk.part),
0, 0, 0, VTOP(&bootinfo));
....
[[boot-loader]]
== loader Stage
-loader is a BTX client as well. I will not describe it here in detail, there is a comprehensive man page written by Mike Smith, man:loader[8]. The underlying mechanisms and BTX were discussed above.
+loader is a BTX client as well.
+I will not describe it here in detail, there is a comprehensive man page written by Mike Smith, man:loader[8].
+The underlying mechanisms and BTX were discussed above.
-The main task for the loader is to boot the kernel. When the kernel is loaded into memory, it is being called by the loader:
+The main task for the loader is to boot the kernel.
+When the kernel is loaded into memory, it is being called by the loader:
[.programlisting]
....
-sys/boot/common/boot.c:
+stand/common/boot.c:
/* Call the exec handler from the loader matching the kernel */
- module_formats[km->m_loader]->l_exec(km);
+ file_formats[fp->f_loader]->l_exec(fp);
....
[[boot-kernel]]
== Kernel Initialization
-Let us take a look at the command that links the kernel. This will help identify the exact location where the loader passes execution to the kernel. This location is the kernel's actual entry point.
+Let us take a look at the command that links the kernel.
+This will help identify the exact location where the loader passes execution to the kernel.
+This location is the kernel's actual entry point.
+This command is now excluded from [.filename]#sys/conf/Makefile.i386#.
+The content that interests us can be found in [.filename]#/usr/obj/usr/src/i386.i386/sys/GENERIC/#.
[.programlisting]
....
-sys/conf/Makefile.i386:
-ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386 -export-dynamic \
--dynamic-linker /red/herring -o kernel -X locore.o \
+/usr/obj/usr/src/i386.i386/sys/GENERIC/kernel.meta:
+ld -m elf_i386_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.i386 --build-id=sha1 --no-warn-mismatch \
+--warn-common --export-dynamic --dynamic-linker /red/herring -X -o kernel locore.o
<lots of kernel .o files>
....
-A few interesting things can be seen here. First, the kernel is an ELF dynamically linked binary, but the dynamic linker for kernel is [.filename]#/red/herring#, which is definitely a bogus file. Second, taking a look at the file [.filename]#sys/conf/ldscript.i386# gives an idea about what ld options are used when compiling a kernel. Reading through the first few lines, the string
+A few interesting things can be seen here.
+First, the kernel is an ELF dynamically linked binary, but the dynamic linker for kernel is [.filename]#/red/herring#, which is definitely a bogus file.
+Second, taking a look at the file [.filename]#sys/conf/ldscript.i386# gives an idea about what ld options are used when compiling a kernel.
+Reading through the first few lines, the string
[.programlisting]
....
@@ -927,7 +1242,8 @@ sys/conf/ldscript.i386:
ENTRY(btext)
....
-says that a kernel's entry point is the symbol `btext`. This symbol is defined in [.filename]#locore.s#:
+says that a kernel's entry point is the symbol `btext`.
+This symbol is defined in [.filename]#locore.s#:
[.programlisting]
....
@@ -941,7 +1257,8 @@ sys/i386/i386/locore.s:
NON_GPROF_ENTRY(btext)
....
-First, the register EFLAGS is set to a predefined value of 0x00000002. Then all the segment registers are initialized:
+First, the register EFLAGS is set to a predefined value of 0x00000002.
+Then all the segment registers are initialized:
[.programlisting]
....
@@ -959,39 +1276,40 @@ sys/i386/i386/locore.s:
mov %ax, %gs
....
-btext calls the routines `recover_bootinfo()`, `identify_cpu()`, `create_pagetables()`, which are also defined in [.filename]#locore.s#. Here is a description of what they do:
+btext calls the routines `recover_bootinfo()`, `identify_cpu()`, which are also defined in [.filename]#locore.s#.
+Here is a description of what they do:
[.informaltable]
[cols="1,1", frame="none"]
|===
|`recover_bootinfo`
-|This routine parses the parameters to the kernel passed from the bootstrap. The kernel may have been booted in 3 ways: by the loader, described above, by the old disk boot blocks, or by the old diskless boot procedure. This function determines the booting method, and stores the `struct bootinfo` structure into the kernel memory.
+|This routine parses the parameters to the kernel passed from the bootstrap.
+The kernel may have been booted in 3 ways: by the loader, described above, by the old disk boot blocks, or by the old diskless boot procedure.
+This function determines the booting method, and stores the `struct bootinfo` structure into the kernel memory.
|`identify_cpu`
-|This functions tries to find out what CPU it is running on, storing the value found in a variable `_cpu`.
-
-|`create_pagetables`
-|This function allocates and fills out a Page Table Directory at the top of the kernel memory area.
+|This function tries to find out what CPU it is running on, storing the value found in a variable `_cpu`.
|===
The next steps are enabling VME, if the CPU supports it:
[.programlisting]
....
- testl $CPUID_VME, R(_cpu_feature)
- jz 1f
- movl %cr4, %eax
- orl $CR4_VME, %eax
- movl %eax, %cr4
+sys/i386/i386/mpboot.s:
+ testl $CPUID_VME,%edx
+ jz 3f
+ orl $CR4_VME,%eax
+3: movl %eax,%cr4
....
Then, enabling paging:
[.programlisting]
....
+sys/i386/i386/mpboot.s:
/* Now enable paging */
- movl R(_IdlePTD), %eax
+ movl IdlePTD_nopae, %eax
movl %eax,%cr3 /* load ptd addr into mmu */
movl %cr0,%eax /* get control word */
orl $CR0_PE|CR0_PG,%eax /* enable paging */
@@ -1002,28 +1320,34 @@ The next three lines of code are because the paging was set, so the jump is need
[.programlisting]
....
- pushl $begin /* jump to high virtualized address */
+sys/i386/i386/mpboot.s:
+ pushl $mp_begin /* jump to high mem */
ret
/* now running relocated at KERNBASE where the system is linked to run */
-begin:
+mp_begin: /* now running relocated at KERNBASE */
....
-The function `init386()` is called with a pointer to the first free physical page, after that `mi_startup()`. `init386` is an architecture dependent initialization function, and `mi_startup()` is an architecture independent one (the 'mi_' prefix stands for Machine Independent). The kernel never returns from `mi_startup()`, and by calling it, the kernel finishes booting:
+The function `init386()` is called with a pointer to the first free physical page, after that `mi_startup()`.
+`init386` is an architecture dependent initialization function, and `mi_startup()` is an architecture independent one (the 'mi_' prefix stands for Machine Independent).
+The kernel never returns from `mi_startup()`, and by calling it, the kernel finishes booting:
[.programlisting]
....
sys/i386/i386/locore.s:
- movl physfree, %esi
- pushl %esi /* value of first for init386(first) */
- call _init386 /* wire 386 chip for unix operation */
- call _mi_startup /* autoconfiguration, mountroot etc */
- hlt /* never returns to here */
+ pushl physfree /* value of first for init386(first) */
+ call init386 /* wire 386 chip for unix operation */
+ addl $4,%esp
+ movl %eax,%esp /* Switch to true top of stack. */
+ call mi_startup /* autoconfiguration, mountroot etc */
+ /* NOTREACHED */
....
=== `init386()`
-`init386()` is defined in [.filename]#sys/i386/i386/machdep.c# and performs low-level initialization specific to the i386 chip. The switch to protected mode was performed by the loader. The loader has created the very first task, in which the kernel continues to operate. Before looking at the code, consider the tasks the processor must complete to initialize protected mode execution:
+`init386()` is defined in [.filename]#sys/i386/i386/machdep.c# and performs low-level initialization specific to the i386 chip.The switch to protected mode was performed by the loader.
+The loader has created the very first task, in which the kernel continues to operate.
+Before looking at the code, consider the tasks the processor must complete to initialize protected mode execution:
* Initialize the kernel tunable parameters, passed from the bootstrapping program.
* Prepare the GDT.
@@ -1032,26 +1356,28 @@ sys/i386/i386/locore.s:
* Initialize the DDB, if it is compiled into kernel.
* Initialize the TSS.
* Prepare the LDT.
-* Set up proc0's pcb.
+* Set up thread0's pcb.
-`init386()` initializes the tunable parameters passed from bootstrap by setting the environment pointer (envp) and calling `init_param1()`. The envp pointer has been passed from loader in the `bootinfo` structure:
+`init386()` initializes the tunable parameters passed from bootstrap by setting the environment pointer (envp) and calling `init_param1()`.
+The envp pointer has been passed from loader in the `bootinfo` structure:
[.programlisting]
....
sys/i386/i386/machdep.c:
- kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
-
/* Init basic tunables, hz etc */
init_param1();
....
-`init_param1()` is defined in [.filename]#sys/kern/subr_param.c#. That file has a number of sysctls, and two functions, `init_param1()` and `init_param2()`, that are called from `init386()`:
+`init_param1()` is defined in [.filename]#sys/kern/subr_param.c#.
+That file has a number of sysctls, and two functions, `init_param1()` and `init_param2()`, that are called from `init386()`:
[.programlisting]
....
sys/kern/subr_param.c:
- hz = HZ;
+ hz = -1;
TUNABLE_INT_FETCH("kern.hz", &hz);
+ if (hz == -1)
+ hz = vm_guest > VM_GUEST_NO ? HZ_VM : HZ;
....
TUNABLE_<typename>_FETCH is used to fetch the value from the environment:
@@ -1062,39 +1388,59 @@ TUNABLE_<typename>_FETCH is used to fetch the value from the environment:
#define TUNABLE_INT_FETCH(path, var) getenv_int((path), (var))
....
-Sysctl `kern.hz` is the system clock tick. Additionally, these sysctls are set by `init_param1()`: `kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz`.
+Sysctl `kern.hz` is the system clock tick.
+Additionally, these sysctls are set by `init_param1()`: `kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz`.
-Then `init386()` prepares the Global Descriptors Table (GDT). Every task on an x86 is running in its own virtual address space, and this space is addressed by a segment:offset pair. Say, for instance, the current instruction to be executed by the processor lies at CS:EIP, then the linear virtual address for that instruction would be "the virtual address of code segment CS" + EIP. For convenience, segments begin at virtual address 0 and end at a 4Gb boundary. Therefore, the instruction's linear virtual address for this example would just be the value of EIP. Segment registers such as CS, DS etc are the selectors, i.e., indexes, into GDT (to be more precise, an index is not a selector itself, but the INDEX field of a selector). FreeBSD's GDT holds descriptors for 15 selectors per CPU:
+Then `init386()` prepares the Global Descriptors Table (GDT).
+Every task on an x86 is running in its own virtual address space, and this space is addressed by a segment:offset pair.
+Say, for instance, the current instruction to be executed by the processor lies at CS:EIP, then the linear virtual address for that instruction would be "the virtual address of code segment CS" + EIP.
+For convenience, segments begin at virtual address 0 and end at a 4GB boundary.
+Therefore, the instruction's linear virtual address for this example would just be the value of EIP.
+Segment registers such as CS, DS etc are the selectors, i.e., indexes, into GDT (to be more precise, an index is not a selector itself, but the INDEX field of a selector).
+FreeBSD's GDT holds descriptors for 15 selectors per CPU:
[.programlisting]
....
sys/i386/i386/machdep.c:
-union descriptor gdt[NGDT * MAXCPU]; /* global descriptor table */
+union descriptor gdt0[NGDT]; /* initial global descriptor table */
+union descriptor *gdt = gdt0; /* global descriptor table */
-sys/i386/include/segments.h:
+sys/x86/include/segments.h:
/*
* Entries in the Global Descriptor Table (GDT)
*/
#define GNULL_SEL 0 /* Null Descriptor */
-#define GCODE_SEL 1 /* Kernel Code Descriptor */
-#define GDATA_SEL 2 /* Kernel Data Descriptor */
-#define GPRIV_SEL 3 /* SMP Per-Processor Private Data */
-#define GPROC0_SEL 4 /* Task state process slot zero and up */
-#define GLDT_SEL 5 /* LDT - eventually one per process */
-#define GUSERLDT_SEL 6 /* User LDT */
-#define GTGATE_SEL 7 /* Process task switch gate */
+#define GPRIV_SEL 1 /* SMP Per-Processor Private Data */
+#define GUFS_SEL 2 /* User %fs Descriptor (order critical: 1) */
+#define GUGS_SEL 3 /* User %gs Descriptor (order critical: 2) */
+#define GCODE_SEL 4 /* Kernel Code Descriptor (order critical: 1) */
+#define GDATA_SEL 5 /* Kernel Data Descriptor (order critical: 2) */
+#define GUCODE_SEL 6 /* User Code Descriptor (order critical: 3) */
+#define GUDATA_SEL 7 /* User Data Descriptor (order critical: 4) */
#define GBIOSLOWMEM_SEL 8 /* BIOS low memory access (must be entry 8) */
-#define GPANIC_SEL 9 /* Task state to consider panic from */
-#define GBIOSCODE32_SEL 10 /* BIOS interface (32bit Code) */
-#define GBIOSCODE16_SEL 11 /* BIOS interface (16bit Code) */
-#define GBIOSDATA_SEL 12 /* BIOS interface (Data) */
-#define GBIOSUTIL_SEL 13 /* BIOS interface (Utility) */
-#define GBIOSARGS_SEL 14 /* BIOS interface (Arguments) */
-....
-
-Note that those #defines are not selectors themselves, but just a field INDEX of a selector, so they are exactly the indices of the GDT. for example, an actual selector for the kernel code (GCODE_SEL) has the value 0x08.
-
-The next step is to initialize the Interrupt Descriptor Table (IDT). This table is referenced by the processor when a software or hardware interrupt occurs. For example, to make a system call, user application issues the `INT 0x80` instruction. This is a software interrupt, so the processor's hardware looks up a record with index 0x80 in the IDT. This record points to the routine that handles this interrupt, in this particular case, this will be the kernel's syscall gate. The IDT may have a maximum of 256 (0x100) records. The kernel allocates NIDT records for the IDT, where NIDT is the maximum (256):
+#define GPROC0_SEL 9 /* Task state process slot zero and up */
+#define GLDT_SEL 10 /* Default User LDT */
+#define GUSERLDT_SEL 11 /* User LDT */
+#define GPANIC_SEL 12 /* Task state to consider panic from */
+#define GBIOSCODE32_SEL 13 /* BIOS interface (32bit Code) */
+#define GBIOSCODE16_SEL 14 /* BIOS interface (16bit Code) */
+#define GBIOSDATA_SEL 15 /* BIOS interface (Data) */
+#define GBIOSUTIL_SEL 16 /* BIOS interface (Utility) */
+#define GBIOSARGS_SEL 17 /* BIOS interface (Arguments) */
+#define GNDIS_SEL 18 /* For the NDIS layer */
+#define NGDT 19
+....
+
+Note that those #defines are not selectors themselves, but just a field INDEX of a selector, so they are exactly the indices of the GDT.
+for example, an actual selector for the kernel code (GCODE_SEL) has the value 0x20.
+
+The next step is to initialize the Interrupt Descriptor Table (IDT).
+This table is referenced by the processor when a software or hardware interrupt occurs.
+For example, to make a system call, user application issues the `INT 0x80` instruction.
+This is a software interrupt, so the processor's hardware looks up a record with index 0x80 in the IDT.
+This record points to the routine that handles this interrupt, in this particular case, this will be the kernel's syscall gate.
+The IDT may have a maximum of 256 (0x100) records.
+The kernel allocates NIDT records for the IDT, where NIDT is the maximum (256):
[.programlisting]
....
@@ -1103,13 +1449,14 @@ static struct gate_descriptor idt0[NIDT];
struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table */
....
-For each interrupt, an appropriate handler is set. The syscall gate for `INT 0x80` is set as well:
+For each interrupt, an appropriate handler is set.
+The syscall gate for `INT 0x80` is set as well:
[.programlisting]
....
sys/i386/i386/machdep.c:
- setidt(0x80, &IDTVEC(int0x80_syscall),
- SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));
+ setidt(IDT_SYSCALL, &IDTVEC(int0x80_syscall),
+ SDT_SYS386IGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));
....
So when a userland application issues the `INT 0x80` instruction, control will transfer to the function `_Xint0x80_syscall`, which is in the kernel code segment and will be executed with supervisor privileges.
@@ -1121,41 +1468,47 @@ Console and DDB are then initialized:
sys/i386/i386/machdep.c:
cninit();
/* skipped */
-#ifdef DDB
- kdb_init();
+ kdb_init();
+#ifdef KDB
if (boothowto & RB_KDB)
- Debugger("Boot flags requested debugger");
+ kdb_enter(KDB_WHY_BOOTFLAGS, "Boot flags requested debugger");
#endif
....
The Task State Segment is another x86 protected mode structure, the TSS is used by the hardware to store task information when a task switch occurs.
-The Local Descriptors Table is used to reference userland code and data. Several selectors are defined to point to the LDT, they are the system call gates and the user code and data selectors:
+The Local Descriptors Table is used to reference userland code and data.
+Several selectors are defined to point to the LDT, they are the system call gates and the user code and data selectors:
[.programlisting]
....
-/usr/include/machine/segments.h:
+sys/x86/include/segments.h:
#define LSYS5CALLS_SEL 0 /* forced by intel BCS */
#define LSYS5SIGR_SEL 1
-#define L43BSDCALLS_SEL 2 /* notyet */
#define LUCODE_SEL 3
-#define LSOL26CALLS_SEL 4 /* Solaris >= 2.6 system call gate */
#define LUDATA_SEL 5
-/* separate stack, es,fs,gs sels ? */
-/* #define LPOSIXCALLS_SEL 5*/ /* notyet */
-#define LBSDICALLS_SEL 16 /* BSDI system call gate */
-#define NLDT (LBSDICALLS_SEL + 1)
+#define NLDT (LUDATA_SEL + 1)
....
-Next, proc0's Process Control Block (`struct pcb`) structure is initialized. proc0 is a `struct proc` structure that describes a kernel process. It is always present while the kernel is running, therefore it is declared as global:
+Next, proc0's Process Control Block (`struct pcb`) structure is initialized.
+proc0 is a `struct proc` structure that describes a kernel process.
+It is always present while the kernel is running, therefore it is linked with thread0:
[.programlisting]
....
-sys/kern/kern_init.c:
- struct proc proc0;
+sys/i386/i386/machdep.c:
+register_t
+init386(int first)
+{
+ /* ... skipped ... */
+
+ proc_linkup0(&proc0, &thread0);
+ /* ... skipped ... */
+}
....
-The structure `struct pcb` is a part of a proc structure. It is defined in [.filename]#/usr/include/machine/pcb.h# and has a process's information specific to the i386 architecture, such as registers values.
+The structure `struct pcb` is a part of a proc structure.
+It is defined in [.filename]#/usr/include/machine/pcb.h# and has a process's information specific to the i386 architecture, such as registers values.
=== `mi_startup()`
@@ -1164,7 +1517,7 @@ This function performs a bubble sort of all the system initialization objects an
[.programlisting]
....
sys/kern/init_main.c:
- for (sipp = sysinit; *sipp; sipp++) {
+ for (sipp = sysinit; sipp < sysinit_end; sipp++) {
/* ... skipped ... */
@@ -1176,7 +1529,9 @@ sys/kern/init_main.c:
Although the sysinit framework is described in the link:/books/developers-handbook[Developers' Handbook], I will discuss the internals of it.
-Every system initialization object (sysinit object) is created by calling a SYSINIT() macro. Let us take as example an `announce` sysinit object. This object prints the copyright message:
+Every system initialization object (sysinit object) is created by calling a SYSINIT() macro.
+Let us take as example an `announce` sysinit object.
+This object prints the copyright message:
[.programlisting]
....
@@ -1186,104 +1541,82 @@ print_caddr_t(void *data __unused)
{
printf("%s", (char *)data);
}
-SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)
+/* ... skipped ... */
+SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright);
....
-The subsystem ID for this object is SI_SUB_COPYRIGHT (0x0800001), which comes right after the SI_SUB_CONSOLE (0x0800000). So, the copyright message will be printed out first, just after the console initialization.
+The subsystem ID for this object is SI_SUB_COPYRIGHT (0x0800001).
+So, the copyright message will be printed out first, just after the console initialization.
-Let us take a look at what exactly the macro `SYSINIT()` does. It expands to a `C_SYSINIT()` macro. The `C_SYSINIT()` macro then expands to a static `struct sysinit` structure declaration with another `DATA_SET` macro call:
+Let us take a look at what exactly the macro `SYSINIT()` does.
+It expands to a `C_SYSINIT()` macro.
+The `C_SYSINIT()` macro then expands to a static `struct sysinit` structure declaration with another `DATA_SET` macro call:
[.programlisting]
....
/usr/include/sys/kernel.h:
#define C_SYSINIT(uniquifier, subsystem, order, func, ident) \
static struct sysinit uniquifier ## _sys_init = { \ subsystem, \
- order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ##
+ order, \ func, \ (ident) \ }; \ DATA_WSET(sysinit_set,uniquifier ##
_sys_init);
#define SYSINIT(uniquifier, subsystem, order, func, ident) \
C_SYSINIT(uniquifier, subsystem, order, \
- (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident)
+ (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)(ident))
....
-The `DATA_SET()` macro expands to a `MAKE_SET()`, and that macro is the point where all the sysinit magic is hidden:
+The `DATA_SET()` macro expands to a `_MAKE_SET()`, and that macro is the point where all the sysinit magic is hidden:
[.programlisting]
....
/usr/include/linker_set.h:
-#define MAKE_SET(set, sym) \
- static void const * const __set_##set##_sym_##sym = sym; \
- __asm(".section .set." #set ",\"aw\""); \
- __asm(".long " #sym); \
- __asm(".previous")
-#endif
-#define TEXT_SET(set, sym) MAKE_SET(set, sym)
-#define DATA_SET(set, sym) MAKE_SET(set, sym)
+#define TEXT_SET(set, sym) _MAKE_SET(set, sym)
+#define DATA_SET(set, sym) _MAKE_SET(set, sym)
....
-In our case, the following declaration will occur:
-
-[.programlisting]
-....
-static struct sysinit announce_sys_init = {
- SI_SUB_COPYRIGHT,
- SI_ORDER_FIRST,
- (sysinit_cfunc_t)(sysinit_nfunc_t) print_caddr_t,
- (void *) copyright
-};
-
-static void const *const __set_sysinit_set_sym_announce_sys_init =
- announce_sys_init;
-__asm(".section .set.sysinit_set" ",\"aw\"");
-__asm(".long " "announce_sys_init");
-__asm(".previous");
-....
-
-The first `__asm` instruction will create an ELF section within the kernel's executable. This will happen at kernel link time. The section will have the name `.set.sysinit_set`. The content of this section is one 32-bit value, the address of announce_sys_init structure, and that is what the second `__asm` is. The third `__asm` instruction marks the end of a section. If a directive with the same section name occurred before, the content, i.e., the 32-bit value, will be appended to the existing section, so forming an array of 32-bit pointers.
-
+After executing these macros, various sections were made in the kernel, including`set.sysinit_set`.
Running objdump on a kernel binary, you may notice the presence of such small sections:
[source,bash]
....
-% objdump -h /kernel
- 7 .set.cons_set 00000014 c03164c0 c03164c0 002154c0 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 8 .set.kbddriver_set 00000010 c03164d4 c03164d4 002154d4 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 9 .set.scrndr_set 00000024 c03164e4 c03164e4 002154e4 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 10 .set.scterm_set 0000000c c0316508 c0316508 00215508 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 11 .set.sysctl_set 0000097c c0316514 c0316514 00215514 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 12 .set.sysinit_set 00000664 c0316e90 c0316e90 00215e90 2**2
- CONTENTS, ALLOC, LOAD, DATA
+% llvm-objdump -h /kernel
+Sections:
+Idx Name Size VMA Type
+ 10 set_sysctl_set 000021d4 01827078 DATA
+ 16 set_kbddriver_set 00000010 0182a4d0 DATA
+ 20 set_scterm_set 0000000c 0182c75c DATA
+ 21 set_cons_set 00000014 0182c768 DATA
+ 33 set_scrndr_set 00000024 0182c828 DATA
+ 41 set_sysinit_set 000014d8 018fabb0 DATA
....
-This screen dump shows that the size of .set.sysinit_set section is 0x664 bytes, so `0x664/sizeof(void *)` sysinit objects are compiled into the kernel. The other sections such as `.set.sysctl_set` represent other linker sets.
+This screen dump shows that the size of set.sysinit_set section is 0x14d8 bytes, so `0x14d8/sizeof(void *)` sysinit objects are compiled into the kernel.
+The other sections such as `set.sysctl_set` represent other linker sets.
-By defining a variable of type `struct linker_set` the content of `.set.sysinit_set` section will be "collected" into that variable:
+By defining a variable of type `struct sysinit` the content of `set.sysinit_set` section will be "collected" into that variable:
[.programlisting]
....
sys/kern/init_main.c:
- extern struct linker_set sysinit_set; /* XXX */
+ SET_DECLARE(sysinit_set, struct sysinit);
....
-The `struct linker_set` is defined as follows:
+The `struct sysinit` is defined as follows:
[.programlisting]
....
-/usr/include/linker_set.h:
- struct linker_set {
- int ls_length;
- void *ls_items[1]; /* really ls_length of them, trailing NULL */
+sys/sys/kernel.h:
+ struct sysinit {
+ enum sysinit_sub_id subsystem; /* subsystem identifier*/
+ enum sysinit_elem_order order; /* init order within subsystem*/
+ sysinit_cfunc_t func; /* function */
+ const void *udata; /* multiplexer/argument */
};
....
-The first node will be equal to the number of a sysinit objects, and the second node will be a NULL-terminated array of pointers to them.
-
-Returning to the `mi_startup()` discussion, it is must be clear now, how the sysinit objects are being organized. The `mi_startup()` function sorts them and calls each. The very last object is the system scheduler:
+Returning to the `mi_startup()` discussion, it is must be clear now, how the sysinit objects are being organized.
+The `mi_startup()` function sorts them and calls each.
+The very last object is the system scheduler:
[.programlisting]
....
@@ -1291,14 +1624,16 @@ Returning to the `mi_startup()` discussion, it is must be clear now, how the sys
enum sysinit_sub_id {
SI_SUB_DUMMY = 0x0000000, /* not executed; for linker*/
SI_SUB_DONE = 0x0000001, /* processed*/
- SI_SUB_CONSOLE = 0x0800000, /* console*/
+ SI_SUB_TUNABLES = 0x0700000, /* establish tunable values */
SI_SUB_COPYRIGHT = 0x0800001, /* first use of console*/
...
- SI_SUB_RUN_SCHEDULER = 0xfffffff /* scheduler: no return*/
+ SI_SUB_LAST = 0xfffffff /* final initialization */
};
....
-The system scheduler sysinit object is defined in the file [.filename]#sys/vm/vm_glue.c#, and the entry point for that object is `scheduler()`. That function is actually an infinite loop, and it represents a process with PID 0, the swapper process. The proc0 structure, mentioned before, is used to describe it.
+The system scheduler sysinit object is defined in the file [.filename]#sys/vm/vm_glue.c#, and the entry point for that object is `scheduler()`.
+That function is actually an infinite loop, and it represents a process with PID 0, the swapper process.
+The thread0 structure, mentioned before, is used to describe it.
The first user process, called _init_, is created by the sysinit object `init`:
@@ -1308,22 +1643,49 @@ sys/kern/init_main.c:
static void
create_init(const void *udata __unused)
{
+ struct fork_req fr;
+ struct ucred *newcred, *oldcred;
+ struct thread *td;
int error;
- int s;
- s = splhigh();
- error = fork1(proc0, RFFDG | RFPROC, initproc);
+ bzero(&fr, sizeof(fr));
+ fr.fr_flags = RFFDG | RFPROC | RFSTOPPED;
+ fr.fr_procp = &initproc;
+ error = fork1(&thread0, &fr);
if (error)
panic("cannot fork init: %d\n", error);
- initproc-p_flag |= P_INMEM | P_SYSTEM;
- cpu_set_fork_handler(initproc, start_init, NULL);
- remrunqueue(initproc);
- splx(s);
+ KASSERT(initproc->p_pid == 1, ("create_init: initproc->p_pid != 1"));
+ /* divorce init's credentials from the kernel's */
+ newcred = crget();
+ sx_xlock(&proctree_lock);
+ PROC_LOCK(initproc);
+ initproc->p_flag |= P_SYSTEM | P_INMEM;
+ initproc->p_treeflag |= P_TREE_REAPER;
+ oldcred = initproc->p_ucred;
+ crcopy(newcred, oldcred);
+#ifdef MAC
+ mac_cred_create_init(newcred);
+#endif
+#ifdef AUDIT
+ audit_cred_proc1(newcred);
+#endif
+ proc_set_cred(initproc, newcred);
+ td = FIRST_THREAD_IN_PROC(initproc);
+ crcowfree(td);
+ td->td_realucred = crcowget(initproc->p_ucred);
+ td->td_ucred = td->td_realucred;
+ PROC_UNLOCK(initproc);
+ sx_xunlock(&proctree_lock);
+ crfree(oldcred);
+ cpu_fork_kthread_handler(FIRST_THREAD_IN_PROC(initproc), start_init, NULL);
}
-SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL)
+SYSINIT(init, SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL);
....
-The `create_init()` allocates a new process by calling `fork1()`, but does not mark it runnable. When this new process is scheduled for execution by the scheduler, the `start_init()` will be called. That function is defined in [.filename]#init_main.c#. It tries to load and exec the [.filename]#init# binary, probing [.filename]#/sbin/init# first, then [.filename]#/sbin/oinit#, [.filename]#/sbin/init.bak#, and finally [.filename]#/stand/sysinstall#:
+The function `create_init()` allocates a new process by calling `fork1()`, but does not mark it runnable.
+When this new process is scheduled for execution by the scheduler, the `start_init()` will be called.
+That function is defined in [.filename]#init_main.c#.
+It tries to load and exec the [.filename]#init# binary, probing [.filename]#/sbin/init# first, then [.filename]#/sbin/oinit#, [.filename]#/sbin/init.bak#, and finally [.filename]#/rescue/init#:
[.programlisting]
....
@@ -1332,6 +1694,6 @@ static char init_path[MAXPATHLEN] =
#ifdef INIT_PATH
__XSTRING(INIT_PATH);
#else
- "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall";
+ "/sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init";
#endif
....
diff --git a/documentation/content/en/books/developers-handbook/_index.adoc b/documentation/content/en/books/developers-handbook/_index.adoc
index add9336ec8..503fd905f8 100644
--- a/documentation/content/en/books/developers-handbook/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/_index.adoc
@@ -54,6 +54,6 @@ Many sections do not yet exist and some of those that do exist need to be update
If you are interested in helping with this project, send email to the {freebsd-doc}.
The latest version of this document is always available from the link:https://www.FreeBSD.org[FreeBSD World Wide Web server].
-It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp].
+It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD download server] or one of the numerous extref:{handbook}[mirror sites, mirrors].
'''
diff --git a/documentation/content/en/books/developers-handbook/book.adoc b/documentation/content/en/books/developers-handbook/book.adoc
index 06061218ff..3cb4f7ccca 100644
--- a/documentation/content/en/books/developers-handbook/book.adoc
+++ b/documentation/content/en/books/developers-handbook/book.adoc
@@ -53,7 +53,7 @@ Many sections do not yet exist and some of those that do exist need to be update
If you are interested in helping with this project, send email to the {freebsd-doc}.
The latest version of this document is always available from the link:https://www.FreeBSD.org[FreeBSD World Wide Web server].
-It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp].
+It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD download server] or one of the numerous extref:{handbook}[mirror sites, mirrors].
'''
diff --git a/documentation/content/en/books/developers-handbook/tools/_index.adoc b/documentation/content/en/books/developers-handbook/tools/_index.adoc
index c13521edc9..e94ebd62cb 100644
--- a/documentation/content/en/books/developers-handbook/tools/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/tools/_index.adoc
@@ -656,7 +656,7 @@ as they are very complicated (and if you do look at them, make sure you have a f
Unfortunately, there are several different versions of `make`, and they all differ considerably.
The best way to learn what they can do is probably to read the documentation-hopefully this introduction will have given you a base from which you can do this.
-The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in [.filename]#/usr/share/doc/psd/12.make#.
+The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in [.filename]#/usr/src/share/doc/psd/12.make#.
To view it, do
[source,bash]
diff --git a/documentation/content/en/books/faq/_index.adoc b/documentation/content/en/books/faq/_index.adoc
index b66099da8d..de3500ff6e 100644
--- a/documentation/content/en/books/faq/_index.adoc
+++ b/documentation/content/en/books/faq/_index.adoc
@@ -2,7 +2,7 @@
title: Frequently Asked Questions for FreeBSD 12.X and 13.X
authors:
- author: The FreeBSD Documentation Project
-copyright: 1995-2021 The FreeBSD Documentation Project
+copyright: 1995-2022 The FreeBSD Documentation Project
description: Frequently Asked Questions, and answers, covering all aspects of FreeBSD
trademarks: ["freebsd", "ibm", "ieee", "adobe", "intel", "linux", "microsoft", "opengroup", "sun", "netbsd", "general"]
bookOrder: 5
@@ -191,8 +191,8 @@ _FreeBSD-CURRENT_, on the other hand, has been one unbroken line since 2.0 was r
For more detailed information on branches see "extref:{releng}[FreeBSD Release Engineering: Creating the Release Branch, rel-branch]",
the status of the branches and the upcoming release schedule can be found on the https://www.FreeBSD.org/releng[Release Engineering Information] page.
-Version https://download.FreeBSD.org/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}] is the latest release from the {rel-stable} branch; it was released in {rel121-current-date}.
-Version https://download.FreeBSD.org/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}] is the latest release from the {rel2-stable} branch; it was released in {rel113-current-date}.
+Version {u-rel123-announce}[{rel123-current}] is the latest release from the {rel2-stable} branch; it was released on {rel123-current-date}.
+Version {u-rel131-announce}[{rel131-current}] is the latest release from the {rel-stable} branch; it was released on {rel131-current-date}.
[[release-freq]]
=== When are FreeBSD releases made?
@@ -237,11 +237,11 @@ and there are no restrictions on who may take part in the discussion.
[[where-get]]
=== Where can I get FreeBSD?
-Every significant release of FreeBSD is available via anonymous FTP from the https://download.FreeBSD.org/releases/[FreeBSD FTP site]:
+Every supported release of FreeBSD is available from the https://www.freebsd.org/where/[FreeBSD release locator page]:
-* The latest {rel-stable} release, {rel121-current}-RELEASE can be found in the https://download.FreeBSD.org/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}-RELEASE directory].
-* link:https://www.FreeBSD.org/snapshots/[Snapshot] releases are made monthly for the <<current,-CURRENT>> and <<stable,-STABLE>> branch, these being of service purely to bleeding-edge testers and developers.
-* The latest {rel2-stable} release, {rel113-current}-RELEASE can be found in the https://download.FreeBSD.org/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}-RELEASE directory].
+* For the latest {rel-stable} release, {rel131-current}-RELEASE, follow the link for link:https://www.freebsd.org/where/#download-rel131[the appropriate architecture and installation mode for {rel131-current}-RELEASE].
+* For the latest {rel2-stable} release, {rel123-current}-RELEASE, follow the link for link:https://www.freebsd.org/where/#download-rel123[the appropriate architecture and installation mode for {rel123-current}-RELEASE].
+* link:https://www.FreeBSD.org/snapshots/[Snapshot] releases are made monthly for the <<current,-CURRENT>> and <<stable,-STABLE>> branches, these being of service purely to bleeding-edge testers and developers.
Information about obtaining FreeBSD on CD, DVD, and other media can be found in extref:{handbook}[the Handbook, mirrors].
@@ -574,7 +574,7 @@ bsdconfig provides a nice interface to configure FreeBSD post-installation.
==== I want to get a piece of hardware for my FreeBSD system. Which model/brand/type is best?
This is discussed continually on the FreeBSD mailing lists but is to be expected since hardware changes so quickly.
-Read through the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}] and search the mailing list https://www.FreeBSD.org/search/#mailinglists[archives] before asking about the latest and greatest hardware.
+Read through the Hardware Notes for FreeBSD link:{u-rel123-hardware}[{rel123-current}] or link:{u-rel131-hardware}[{rel131-current}] and search the https://www.FreeBSD.org/search/#mailinglists[mailing list archives] before asking about the latest and greatest hardware.
Chances are a discussion about that type of hardware took place just last week.
Before purchasing a laptop, check the archives for {freebsd-questions},
@@ -663,7 +663,7 @@ to [.filename]#/etc/rc.conf#
[[supported-peripherals]]
==== What kind of peripherals does FreeBSD support?
-See the complete list in the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}].
+See a list of hardware known to work and any applicable restrictions in the Hardware Notes for FreeBSD link:{u-rel123-hardware}[{rel123-current}] or link:{u-rel131-hardware}[{rel131-current}].
[[compatibility-kbd-mice]]
=== Keyboards and Mice
@@ -740,13 +740,20 @@ bindkey ^[[3~ delete-char # for xterm
==== Workarounds for no sound from my man:pcm[4] sound card?
Some sound cards set their output volume to 0 at every boot.
-Run the following command every time the machine boots:
+On FreeBSD 13 and earlier, run the following command every time the machine boots:
[source,shell]
....
# mixer pcm 100 vol 100 cd 100
....
+Use the following command on FreeBSD 14 and later:
+
+[source,shell]
+....
+# mixer pcm.volume=100 vol.volume=100 cd.volume=100
+....
+
[[power-management-support]]
==== Does FreeBSD support power management on my laptop?
@@ -1898,13 +1905,11 @@ See the man:init[8] manual page for details on `securelevel`, and see [.filename
=== Why is rpc.statd using 256 MB of memory?
No, there is no memory leak, and it is not using 256 MB of memory.
-For convenience, `rpc.statd` maps an obscene amount of memory into its address space.
+For convenience, `rpc.statd` maps a large amount of memory into its address space.
There is nothing terribly wrong with this from a technical standpoint; it just throws off things like man:top[1] and man:ps[1].
-man:rpc.statd[8] maps its status file (resident on [.filename]#/var#) into its address space;
+man:rpc.statd[8] maps its status file ([.filename]#/var/db/statd.status#) into its address space;
to save worrying about remapping the status file later when it needs to grow, it maps the status file with a generous size.
-This is very evident from the source code, where one can see that the length argument to man:mmap[2] is `0x10000000`,
-or one sixteenth of the address space on an IA32, or exactly 256 MB.
[[unsetting-schg]]
=== Why can I not unset the schg file flag?
@@ -2010,9 +2015,9 @@ It is not possible to start X at a raised `securelevel` because X requires write
For more information, see at the man:init[8] manual page.
There are two solutions to the problem:
-set the `securelevel` back down to zero or run man:xdm[1] (or an alternative display manager) at boot time before the `securelevel` is raised.
+set the `securelevel` back down to zero or run man:xdm[8] (or an alternative display manager) at boot time before the `securelevel` is raised.
-See <<xdm-boot>> for more information about running man:xdm[1] at boot time.
+See <<xdm-boot>> for more information about running man:xdm[8] at boot time.
[[x-and-moused]]
=== Why does my mouse not work with X?
@@ -2190,7 +2195,7 @@ For eight active virtual terminals, X will run on the ninth, so use kbd:[Alt+F9]
[[xdm-boot]]
=== How do I start XDM on boot?
-There are two schools of thought on how to start man:xdm[1].
+There are two schools of thought on how to start man:xdm[8].
One school starts `xdm` from [.filename]#/etc/ttys# (see man:ttys[5]) using the supplied example, while the other sets `xdm_enable=yes` in [.filename]#/etc/rc.conf#.
Both are equally valid, and one may work in situations where the other does not.
In both cases the result is the same: X will pop up a graphical login prompt.
@@ -2198,7 +2203,7 @@ In both cases the result is the same: X will pop up a graphical login prompt.
The man:ttys[5] method has the advantage of documenting which vty X will start on and passing the responsibility of restarting the X server on logout to man:init[8].
The man:rc[8] method makes it easy to `kill xdm` if there is a problem starting the X server.
-When using the man:rc[8] method, `xdm_tty` (default `ttyv8`) can be set in [.filename]#/etc/rc.conf# to choose which vty man:xdm[1] opens on.
+When using the man:rc[8] method, `xdm_tty` (default `ttyv8`) can be set in [.filename]#/etc/rc.conf# to choose which vty man:xdm[8] opens on.
[[xconsole-failure]]
=== Why do I get Couldn't open console when I run xconsole?
diff --git a/documentation/content/en/books/fdp-primer/doc-build/_index.adoc b/documentation/content/en/books/fdp-primer/doc-build/_index.adoc
index f240133e53..fe360864e5 100644
--- a/documentation/content/en/books/fdp-primer/doc-build/_index.adoc
+++ b/documentation/content/en/books/fdp-primer/doc-build/_index.adoc
@@ -512,7 +512,7 @@ epub-articles-clean:
<.> The `MAINTAINER` flag specifies who is the maintainer of this Makefile.
<.> `ALL_LANGUAGES` flag specifies in which languages the table of contents has to be generated.
-<.> `RUBY_CMD` flag specifies the location of the Python binary.
+<.> `RUBY_CMD` flag specifies the location of the Ruby binary.
<.> `HUGO_CMD` flag specifies the location of the Hugo binary.
<.> `.ORDER` directives are used to ensure multiple make jobs may run without problem.
<.> `all` target builds the documentation and puts the result in *~/doc/documentation/public*.
diff --git a/documentation/content/en/books/fdp-primer/editor-config/_index.adoc b/documentation/content/en/books/fdp-primer/editor-config/_index.adoc
index 3c865efb2b..bb3314bee6 100644
--- a/documentation/content/en/books/fdp-primer/editor-config/_index.adoc
+++ b/documentation/content/en/books/fdp-primer/editor-config/_index.adoc
@@ -52,13 +52,15 @@ Adjusting your text editor configuration can make working on document files quic
[[editor-config-vim]]
== Vim
-Install from package:editors/vim[], package:editors/vim-console[], or package:editors/vim-tiny[] then follow the configuration instructions in <<editor-config-vim-config>>.
+Install from package:editors/vim[], or package:editors/vim-console[], then follow the configuration instructions in <<editor-config-vim-config>>.
+More advanced users can use a proper linter like link:https://github.com/dense-analysis/ale[Ale] which can also act as a Vim link:https://langserver.org/[Language Server Protocol] client.
[[editor-config-vim-use]]
=== Use
-Press kbd:[P] to reformat paragraphs or text that has been selected in Visual mode.
-Press kbd:[T] to replace groups of eight spaces with a tab.
+Manual page writers can use the following keyboard shortcuts to reformat:
+* Press kbd:[P] to reformat paragraphs or text that has been selected in Visual mode.
+* Press kbd:[T] to replace groups of eight spaces with a tab.
[[editor-config-vim-config]]
=== Configuration
@@ -68,43 +70,59 @@ Edit [.filename]#~/.vimrc#, adding these lines to the end of the file:
[.programlisting]
....
if has("autocmd")
- au BufNewFile,BufRead *.sgml,*.ent,*.xsl,*.xml call Set_SGML()
- au BufNewFile,BufRead *.[1-9] call ShowSpecial()
+ au BufNewFile,BufRead *.adoc call Set_ADOC()
+ au BufNewFile,BufRead *.[1-9] call Set_MAN()
endif " has(autocmd)
function Set_Highlights()
- "match ExtraWhitespace /^\s* \s*\|\s\+$/
- highlight default link OverLength ErrorMsg
- match OverLength /\%71v.\+/
- return 0
-endfunction " Set_Highlights()
+ "match ExtraWhitespace /^\s* \s*\|\s\+$/
+ return 0
+endfunction " Set_Highlights_Adoc()
+
+function Set_Highlights_MAN()
+ highlight default link OverLength ErrorMsg
+ match OverLength /\%71v.\+/
+ return 0
+endfunction " Set_Highlights_MAN()
function ShowSpecial()
- setlocal list listchars=tab:>>,trail:*,eol:$
- hi def link nontext ErrorMsg
- return 0
+ setlocal list listchars=tab:>>,trail:*,eol:$
+ hi def link nontext ErrorMsg
+ return 0
endfunction " ShowSpecial()
-function Set_SGML()
- setlocal number
- syn match sgmlSpecial "&[^;]*;"
- setlocal syntax=sgml
- setlocal filetype=xml
- setlocal shiftwidth=2
- setlocal textwidth=70
- setlocal tabstop=8
- setlocal softtabstop=2
- setlocal formatprg="fmt -p"
- setlocal autoindent
- setlocal smartindent
- " Rewrap paragraphs
- noremap P gqj
- " Replace spaces with tabs
- noremap T :s/ /\t/<CR>
- call ShowSpecial()
- call Set_Highlights()
- return 0
-endfunction " Set_SGML()
+function Set_COMMON()
+ setlocal number
+ setlocal shiftwidth=2
+ setlocal tabstop=8
+ setlocal softtabstop=2
+ setlocal formatprg="fmt -p"
+ setlocal autoindent
+ setlocal smartindent
+ call ShowSpecial()
+ call Set_Highlights()
+ return 0
+endfunction " Set_COMMON()
+
+function Set_ADOC()
+ setlocal syntax=asciidoc
+ setlocal filetype=asciidoc
+ call Set_COMMON()
+ return 0
+endfunction " Set_ADOC()
+
+function Set_MAN()
+ setlocal syntax=man
+ setlocal filetype=man
+ setlocal textwidth=70
+ " Rewrap paragraphs
+ noremap P gqj
+ " Replace spaces with tabs
+ noremap T :s/ /\t/<CR>
+ call Set_COMMON()
+ call Set_Highlights_MAN()
+ return 0
+endfunction " Set_Man()
....
[[editor-config-emacs]]
@@ -191,17 +209,48 @@ Install from package:editors/nano[] or package:editors/nano-devel[].
[[editor-config-nano-config]]
=== Configuration
-Copy the sample XML syntax highlight file to the user's home directory:
-
-[source,shell]
-....
-% cp /usr/local/share/nano/xml.nanorc ~/.nanorc
-....
-
-Use an editor to replace the lines in the [.filename]#~/.nanorc# `syntax "xml"` block with these rules:
+Currently there is no adoc/asciidoc syntax highlight file with nano distribution. So let's create one from scratch and use an editor to create new file or add lines in the [.filename]#~/.nanorc# with these contents:
....
-syntax "xml" "\.([jrs]html?|xml|xslt?)$"
+syntax "asciidoc" "\.(adoc|asc|asciidoc)$"
+# main header
+color red "^====+$"
+# h1
+color red "^==[[:space:]].*$"
+color red "^----+$"
+# h2
+color magenta "^===[[:space:]].*$"
+color magenta "^~~~~+$"
+# h4
+color green "^====[[:space:]].*$"
+color green "^\^\^\^\^+$"
+# h5
+color brightblue "^=====[[:space:]].*$"
+color brightblue "^\+\+\+\++$"
+# attributes
+color brightgreen ":.*:"
+color brightred "\{[a-z0-9]*\}"
+color red "\\\{[a-z0-9]*\}"
+color red "\+\+\+\{[a-z0-9]*\}\+\+\+"
+# Paragraph Title
+color yellow "^\..*$"
+# source
+color magenta "^\[(source,.+|NOTE|TIP|IMPORTANT|WARNING|CAUTION)\]"
+# Other markup
+color yellow ".*[[:space:]]\+$"
+color yellow "_[^_]+_"
+color yellow "\*[^\*]+\*"
+color yellow "\+[^\+]+\+"
+color yellow "`[^`]+`"
+color yellow "\^[^\^]+\^"
+color yellow "~[^~]+~"
+color yellow "'[^']+'"
+color cyan "`{1,2}[^']+'{1,2}"
+# bullets
+color brightmagenta "^[[:space:]]*[\*\.-]{1,5}[[:space:]]"
+# anchors
+color brightwhite "\[\[.*\]\]"
+color brightwhite "<<.*>>"
# trailing whitespace
color ,blue "[[:space:]]+$"
# multiples of eight spaces at the start a line
@@ -211,8 +260,6 @@ color ,blue "^([TAB]*[ ]{8})+"
color ,yellow "( )+TAB"
# highlight indents that have an odd number of spaces
color ,red "^(([ ]{2})+|(TAB+))*[ ]{1}[^ ]{1}"
-# lines longer than 70 characters
-color ,yellow "^(.{71})|(TAB.{63})|(TAB{2}.{55})|(TAB{3}.{47}).+$"
....
Process the file to create embedded tabs:
@@ -229,7 +276,7 @@ Specify additional helpful options when running the editor:
[source,shell]
....
-% nano -AKipwz -r 70 -T8 _index.adoc
+% nano -AKipwz -T8 _index.adoc
....
Users of man:csh[1] can define an alias in [.filename]#~/.cshrc# to automate these options:
diff --git a/documentation/content/en/books/fdp-primer/overview/_index.adoc b/documentation/content/en/books/fdp-primer/overview/_index.adoc
index 1daec39462..157e6ea499 100644
--- a/documentation/content/en/books/fdp-primer/overview/_index.adoc
+++ b/documentation/content/en/books/fdp-primer/overview/_index.adoc
@@ -57,11 +57,46 @@ Willingness to contribute is the only membership requirement.
This primer shows how to:
+* Understand the role of documentation and its place in the ecosystem.
* Identify which parts of FreeBSD are maintained by the FDP.
* Install the required documentation tools and files.
* Make changes to the documentation.
* Submit changes back for review and inclusion in the FreeBSD documentation.
+[[overview-documentation-ecosystem]]
+== Documentation in the FreeBSD Ecosystem
+
+All documents are for the benefit of their readers, not their writers or caretakers.
+They should adapt to the reader and not expect the reader to adapt to them.
+
+Never blame the reader for:
+
+* being unable to make use of a document easily or at all
+* finding a document confusing
+* not understanding a document or how to apply it
+* not finding an explicit answer or successfully bridging gaps (or connecting dots) to reason their way to one
+
+Instead, acknowledge that the document is:
+
+* inaccessible
+* confusing
+* hard to understand or apply
+* incomplete
+
+Then, make the document:
+
+* more accessible
+* less confusing
+* clearer
+* more complete
+
+Use the following methods:
+
+* apply link:https://webaim.org/intro/#principles[accessibility best practices] to correct the problem reported and any similar ones you find
+* rework or clarify the confusing structure or language
+* add relevant examples to the part that is hard to understand or apply
+* fill in the gaps or add the missing stepping stones
+
[[overview-quick-start]]
== Quick Start
@@ -70,6 +105,9 @@ First, subscribe to the {freebsd-doc}.
Some team members also interact on the `#bsddocs` IRC channel on http://www.efnet.org/[EFnet].
These people can help with questions or problems involving the documentation.
+[[freebsd-installation-process]]
+=== FreeBSD installation process
+
[.procedure]
====
. Install these packages. The `docproj` _meta-port_ installs all the applications required to do useful work with the FreeBSD documentation.
@@ -98,17 +136,187 @@ Repeat until all of the errors are resolved.
% make
....
+
-. When changes are complete and tested, generate a "diff file":
+. Add all the files with `git add .`, then review the diff with `git diff`. For example:
+
[source,shell]
....
-% cd ~/doc
-% git diff > bsdinstall.diff.txt
+% git add .
+% git diff --staged
....
+
-Give the diff file a descriptive name.
-In the example above, changes have been made to the [.filename]#bsdinstall# portion of the Handbook.
-. Submit the diff file using the web-based https://bugs.FreeBSD.org/bugzilla/enter_bug.cgi?product=Documentation[Problem Report] system. If using the web form, enter a Summary of _[patch] short description of problem_. Select the Component `Documentation`. In the Description field, enter a short description of the changes and any important details about them. Use the btn:[Add an attachment] button to attach the diff file. Finally, use the btn:[Submit Bug] button to submit your diff to the problem report system.
+Make sure that all required files are included, then commit the change to your local branch and generate a patch with `git format-patch`
++
+[source,shell]
+....
+% git commit
+% git format-patch origin/main
+....
++
+Patch generated with `git format-patch` will include author identity and email addresses,
+making it easier for developers to apply (with `git am`) and give proper credit.
++
+[IMPORTANT]
+======
+To make it easier for committers to apply the patch on their working copy of the documentation tree,
+please generate the [.filename]#.diff# from the base of your documentation tree.
+======
++
+In the example above, changes have been made to the *bsdinstall* portion of the Handbook.
++
+. Submit the patch or diff file using the web-based https://bugs.FreeBSD.org/bugzilla/enter_bug.cgi?product=Documentation[Problem Report] system. If using the web form, enter a Summary of _[patch] short description of problem_. Select the Component `Documentation`. In the Description field, enter a short description of the changes and any important details about them. Use the btn:[Add an attachment] button to attach the patch or diff file. Finally, use the btn:[Submit Bug] button to submit your diff to the problem report system.
+====
+
+[[gnu-linux-installation-process]]
+=== GNU/Linux installation process
+
+[.procedure]
+====
+[TIP]
+======
+Hugo version 0.90 or higher must be used
+======
+
+. Install these packages in apt-based systems like Debian or Ubuntu.
+On other GNU/Linux distributions the package names may change.
+Consult your distribution's package manager if in doubt.
++
+[source,shell]
+....
+# apt install hugo ruby-asciidoctor ruby-asciidoctor-pdf ruby-rouge git bmake
+....
++
+. Install a local working copy of the documentation from the FreeBSD repository in [.filename]#~/doc# (see crossref:working-copy[working-copy,The Working Copy]).
++
+[source,shell]
+....
+% git clone https://git.FreeBSD.org/doc.git ~/doc
+....
++
+. Edit the documentation files that require changes. If a file needs major changes, consult the mailing list for input.
++
+Review the output and edit the files to fix any problems shown, then rerun the command to find any remaining problems.
+Repeat until all of the errors are resolved.
++
+. Always build and test the changes before submitting them. Running `bmake` in the top-level directory of the documentation will generate that documentation in HTML format.
++
+[source,shell]
+....
+% bmake run LOCALBASE=/usr
+....
++
+. Add all the files with `git add .`, then review the diff with `git diff`. For example:
++
+[source,shell]
+....
+% git add .
+% git diff --staged
+....
++
+Make sure that all required files are included, then commit the change to your local branch and generate a patch with `git format-patch`
++
+[source,shell]
+....
+% git commit
+% git format-patch origin/main
+....
++
+Patch generated with `git format-patch` will include author identity and email addresses,
+making it easier for developers to apply (with `git am`) and give proper credit.
++
+[IMPORTANT]
+======
+To make it easier for committers to apply the patch on their working copy of the documentation tree,
+please generate the [.filename]#.diff# from the base of your documentation tree.
+======
++
+. Submit the patch or diff file using the web-based https://bugs.FreeBSD.org/bugzilla/enter_bug.cgi?product=Documentation[Problem Report] system.
+If using the web form, enter a Summary of _short description of problem_.
+Select the Component `Documentation`.
+In the Description field, enter a short description of the problem in the _Summary_ field and add _patch_ to the _Keywords_ field.
+Use the btn:[Add an attachment] button to attach the patch or diff file.
+Finally, use the btn:[Submit Bug] button to submit your diff to the problem report system.
+====
+
+[[mac-os-installation-process]]
+=== macOS(R) installation process
+
+[.procedure]
+====
+[TIP]
+======
+Hugo version 0.90 or higher must be used
+======
+
+. Install these packages using link:https://brew.sh/[Homebrew] and link:https://rubygems.org/[RubyGem].
++
+[source,shell]
+....
+$ brew install hugo ruby git bmake asciidoctor
+....
++
+. Add Ruby to the Path.
++
+[source,shell]
+....
+$ echo 'export PATH="/usr/local/opt/ruby/bin:$PATH"' >> ~/.zshrc
+....
++
+. Install the rouge package using RubyGem.
++
+[source,shell]
+....
+$ sudo gem install rouge
+....
++
+. Install a local working copy of the documentation from the FreeBSD repository in [.filename]#~/doc# (see crossref:working-copy[working-copy,The Working Copy]).
++
+[source,shell]
+....
+$ git clone https://git.FreeBSD.org/doc.git ~/doc
+....
++
+. Edit the documentation files that require changes. If a file needs major changes, consult the mailing list for input.
++
+Review the output and edit the files to fix any problems shown, then rerun the command to find any remaining problems.
+Repeat until all of the errors are resolved.
++
+. Always build and test the changes before submitting them. Running `bmake` in the top-level directory of the documentation will generate that documentation in HTML format.
++
+[source,shell]
+....
+$ bmake run LOCALBASE=/usr
+....
+. Add all the files with `git add .`, then review the diff with `git diff`. For example:
++
+[source,shell]
+....
+% git add .
+% git diff --staged
+....
++
+Make sure that all required files are included, then commit the change to your local branch and generate a patch with `git format-patch`
++
+[source,shell]
+....
+% git commit
+% git format-patch origin/main
+....
++
+Patch generated with `git format-patch` will include author identity and email addresses,
+making it easier for developers to apply (with `git am`) and give proper credit.
++
+[IMPORTANT]
+======
+To make it easier for committers to apply the patch on their working copy of the documentation tree,
+please generate the [.filename]#.diff# from the base of your documentation tree.
+======
++
+. Submit the patch or diff file using the web-based https://bugs.FreeBSD.org/bugzilla/enter_bug.cgi?product=Documentation[Problem Report] system.
+If using the web form, enter a Summary of _short description of problem_.
+Select the Component `Documentation`.
+In the Description field, enter a short description of the problem in the _Summary_ field and add _patch_ to the _Keywords_ field.
+Use the btn:[Add an attachment] button to attach the patch or diff file.
+Finally, use the btn:[Submit Bug] button to submit your diff to the problem report system.
====
[[overview-doc]]
@@ -129,7 +337,7 @@ Documentation source for the FreeBSD web site, Handbook, and FAQ is available in
Source for manual pages is available in a separate source repository located at `https://cgit.freebsd.org/src/`.
Documentation commit messages are visible with `git log`.
-Commit messages are also archived at link:{git-doc-all}.
+Commit messages are also archived at link:{dev-commits-doc-all}.
Web frontends to both of these repositories are available at https://cgit.freebsd.org/doc/[] and https://cgit.freebsd.org/src/[].
diff --git a/documentation/content/en/books/fdp-primer/po-translations/_index.adoc b/documentation/content/en/books/fdp-primer/po-translations/_index.adoc
index 5c688ab1c2..fc6da5fcb8 100644
--- a/documentation/content/en/books/fdp-primer/po-translations/_index.adoc
+++ b/documentation/content/en/books/fdp-primer/po-translations/_index.adoc
@@ -187,7 +187,7 @@ _lang_ is a two-character lowercase code.
|Bengali
|Bangladesh
-|[.filename]#bn#
+|[.filename]#bn-bd#
|Danish
|Denmark
diff --git a/documentation/content/en/books/handbook/_index.adoc b/documentation/content/en/books/handbook/_index.adoc
index 3df05a9caa..62bedd2940 100644
--- a/documentation/content/en/books/handbook/_index.adoc
+++ b/documentation/content/en/books/handbook/_index.adoc
@@ -35,28 +35,19 @@ include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
+:chapters-path: content/{{% lang %}}/books/handbook/
endif::[]
ifdef::backend-pdf,backend-epub3[]
+:chapters-path:
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]
ifndef::env-beastie[]
+:chapters-path:
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
-[.abstract-title]
-Abstract
-
-Welcome to FreeBSD! This handbook covers the installation and day to day use of _FreeBSD {rel130-current}-RELEASE_ and _FreeBSD {rel122-current}-RELEASE_.
-This book is the result of ongoing work by many individuals.
-Some sections might be outdated.
-Those interested in helping to update and expand this document should send email to the {freebsd-doc}.
-
-The latest version of this book is available from the https://www.FreeBSD.org/[FreeBSD web site].
-Previous versions can be obtained from https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/].
-The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous link:./mirrors#mirrors-ftp[mirror sites].
-Printed copies can be purchased at the https://www.freebsdmall.com/[FreeBSD Mall].
-Searches can be performed on the handbook and other documents on the link:https://www.FreeBSD.org/search/[search page].
+include::{chapters-path}introduction.adoc[]
'''
diff --git a/documentation/content/en/books/handbook/advanced-networking/_index.adoc b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
index 7812689466..743e6d03a0 100644
--- a/documentation/content/en/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
@@ -377,14 +377,8 @@ This procedure shows the steps required.
[.procedure]
. Obtain the SSID (Service Set Identifier) and PSK (Pre-Shared Key) for the wireless network from the network administrator.
-. Identify the wireless adapter. The FreeBSD [.filename]#GENERIC# kernel includes drivers for many common wireless adapters. If the wireless adapter is one of those models, it will be shown in the output from man:ifconfig[8]:
-+
-[source,shell]
-....
-% ifconfig | grep -B3 -i wireless
-....
-+
-On FreeBSD 11 or higher, use this command instead:
+. Identify the wireless adapter. The FreeBSD [.filename]#GENERIC# kernel includes drivers for many common wireless adapters.
+If the wireless adapter is one of those models, it will be listed in the man:sysctl[8] `net.wlan.devices` variable:
+
[source,shell]
....
@@ -475,15 +469,15 @@ For users who do not want to use modules, it is possible to compile these driver
[.programlisting]
....
-device wlan # 802.11 support
-device wlan_wep # 802.11 WEP support
-device wlan_ccmp # 802.11 CCMP support
-device wlan_tkip # 802.11 TKIP support
-device wlan_amrr # AMRR transmit rate control algorithm
-device ath # Atheros pci/cardbus NIC's
-device ath_hal # pci/cardbus chip support
-options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors
-device ath_rate_sample # SampleRate tx rate control for ath
+device wlan # 802.11 support
+device wlan_wep # 802.11 WEP support
+device wlan_ccmp # 802.11 CCMP support
+device wlan_tkip # 802.11 TKIP support
+device wlan_amrr # AMRR transmit rate control algorithm
+device ath # Atheros pci/cardbus NIC's
+device ath_hal # pci/cardbus chip support
+options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors
+device ath_rate_sample # SampleRate tx rate control for ath
....
With this information in the kernel configuration file, recompile the kernel and reboot the FreeBSD machine.
@@ -549,29 +543,7 @@ Subsequent scan requests do not require the interface to be marked as up again.
The output of a scan request lists each BSS/IBSS network found.
Besides listing the name of the network, the `SSID`, the output also shows the `BSSID`, which is the MAC address of the access point.
-The `CAPS` field identifies the type of each network and the capabilities of the stations operating there:
-
-.Station Capability Codes
-[cols="1,1", frame="none", options="header"]
-|===
-| Capability Code
-| Meaning
-
-|`E`
-|Extended Service Set (ESS). Indicates that the station is part of an infrastructure network rather than an IBSS/ad-hoc network.
-
-|`I`
-|IBSS/ad-hoc network. Indicates that the station is part of an ad-hoc network rather than an ESS network.
-
-|`P`
-|Privacy. Encryption is required for all data frames exchanged within the BSS using cryptographic means such as WEP, TKIP or AES-CCMP.
-
-|`S`
-|Short Preamble. Indicates that the network is using short preambles, defined in 802.11b High Rate/DSSS PHY, and utilizes a 56 bit sync field rather than the 128 bit field used in long preamble mode.
-
-|`s`
-|Short slot time. Indicates that the 802.11g network is using a short slot time because there are no legacy (802.11b) stations present.
-|===
+The `CAPS` field identifies the type of each network and the capabilities of the stations operating there (see the definition of `list scan` in man:ifconfig[8] for more details).
One can also display the current list of known networks with:
@@ -1407,10 +1379,10 @@ Debugging support is provided by man:wpa_supplicant[8]. Try running this utility
net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
....
+
-Many useful statistics are maintained by the 802.11 layer and `wlanstats`, found in [.filename]#/usr/src/tools/tools/net80211#, will dump this information.
+Many useful statistics are maintained by the 802.11 layer and `wlanstats`, found in [.filename]#/usr/src/tools/tools/net80211#, will dump this information.
These statistics should display all errors identified by the 802.11 layer.
However, some errors are identified in the device drivers that lie below the 802.11 layer so they may not show up.
-To diagnose device-specific problems, refer to the drivers' documentation.
+To diagnose device-specific problems, refer to the driver documentation.
If the above information does not help to clarify the problem, submit a problem report and include output from the above tools.
@@ -1947,7 +1919,7 @@ In this situation, using a router-based firewall is difficult because of subnett
A bridge-based firewall can be configured without any IP addressing issues.
Network Tap::
-A bridge can join two network segments in order to inspect all Ethernet frames that pass between them using man:bpf[4] and man:tcpdump[1] on the bridge interface or by sending a copy of all frames out an additional interface known as a span port.
+A bridge can join two network segments in order to inspect all Ethernet frames that pass between them using man:bpf[4] and man:tcpdump[1] on the bridge interface, or by sending a copy of all frames out on an additional interface known as a span port.
Layer 2 VPN::
Two Ethernet networks can be joined across an IP link by bridging the networks to an EtherIP tunnel or a man:tap[4] based solution such as OpenVPN.
@@ -2679,7 +2651,7 @@ If your archives do not fit, which is usually the case for [.filename]#/var# whe
The DHCP server does not need to be the same machine as the TFTP and NFS server, but it needs to be accessible in the network.
-DHCP is not part of the FreeBSD base system but can be installed using the package:net/isc-dhcp43-server[] port or package.
+DHCP is not part of the FreeBSD base system but can be installed using the package:net/isc-dhcp44-server[] port or package.
Once installed, edit the configuration file, [.filename]#/usr/local/etc/dhcpd.conf#.
Configure the `next-server`, `filename`, and `root-path` settings as seen in this example:
diff --git a/documentation/content/en/books/handbook/bibliography/_index.adoc b/documentation/content/en/books/handbook/bibliography/_index.adoc
index db52ba4fff..b5373676ae 100644
--- a/documentation/content/en/books/handbook/bibliography/_index.adoc
+++ b/documentation/content/en/books/handbook/bibliography/_index.adoc
@@ -76,10 +76,11 @@ International books:
English language books:
-* http://www.absoluteFreeBSD.com/[Absolute FreeBSD, 2nd Edition: The Complete Guide to FreeBSD], published by http://www.nostarch.com/[No Starch Press], 2007. ISBN: 978-1-59327-151-0
+* Absolute FreeBSD: The Complete Guide To FreeBSD, Third Edition, published by http://www.nostarch.com/[No Starch Press], 2018. ISBN: 9781593278922
+* The Complete FreeBSD, published by http://www.oreilly.com/[O'Reilly], 2003. ISBN: 0596005164
* http://www.freebsdmall.com/cgi-bin/fm/bsdcomp[The Complete FreeBSD], published by http://www.oreilly.com/[O'Reilly], 2003. ISBN: 0596005164
* http://www.freebsd-corp-net-guide.com/[The FreeBSD Corporate Networker's Guide], published by http://www.awl.com/aw/[Addison-Wesley], 2000. ISBN: 0201704811
-* http://andrsn.stanford.edu/FreeBSD/introbook/[FreeBSD: An Open-Source Operating System for Your Personal Computer], published by The Bit Tree Press, 2001. ISBN: 0971204500
+* FreeBSD: An Open-Source Operating System for Your Personal Computer, published by The Bit Tree Press, 2001. ISBN: 0971204500
* Teach Yourself FreeBSD in 24 Hours, published by http://www.samspublishing.com/[Sams], 2002. ISBN: 0672324245
* FreeBSD 6 Unleashed, published by http://www.samspublishing.com/[Sams], 2006. ISBN: 0672328755
* FreeBSD: The Complete Reference, published by http://books.mcgraw-hill.com[McGrawHill], 2003. ISBN: 0072224096
diff --git a/documentation/content/en/books/handbook/book.adoc b/documentation/content/en/books/handbook/book.adoc
index 292c01ae94..48e624eb9c 100644
--- a/documentation/content/en/books/handbook/book.adoc
+++ b/documentation/content/en/books/handbook/book.adoc
@@ -45,19 +45,7 @@ ifndef::env-beastie[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
-[.abstract-title]
-Abstract
-
-Welcome to FreeBSD! This handbook covers the installation and day to day use of _FreeBSD {rel130-current}-RELEASE_ and _FreeBSD {rel123-current}-RELEASE_.
-This book is the result of ongoing work by many individuals.
-Some sections might be outdated.
-Those interested in helping to update and expand this document should send email to the {freebsd-doc}.
-
-The latest version of this book is available from the https://www.FreeBSD.org/[FreeBSD web site].
-Previous versions can be obtained from https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/].
-The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous crossref:mirrors[mirrors-ftp,mirror sites].
-Printed copies can be purchased at the https://www.freebsdmall.com/[FreeBSD Mall].
-Searches can be performed on the handbook and other documents on the link:https://www.FreeBSD.org/search/[search page].
+include::{chapters-path}introduction.adoc[]
'''
@@ -158,4 +146,8 @@ include::{chapters-path}eresources/_index.adoc[leveloffset=+1]
include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1]
+include::{chapters-path}glossary.adoc[leveloffset=+1]
+
+include::{chapters-path}colophon.adoc[leveloffset=+1]
+
:sectnums:
diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc
index 5fcc5a350f..57e8faf96f 100644
--- a/documentation/content/en/books/handbook/config/_index.adoc
+++ b/documentation/content/en/books/handbook/config/_index.adoc
@@ -1540,26 +1540,6 @@ A value of `10000`, `20000` or `30000` may be reasonable. Consider firewall effe
Some firewalls may block large ranges of ports, usually low-numbered ports, and expect systems to use higher ranges of ports for outgoing connections.
For this reason, it is not recommended that the value of `net.inet.ip.portrange.first` be lowered.
-==== `TCP` Bandwidth Delay Product
-
-`TCP` bandwidth delay product limiting can be enabled by setting the `net.inet.tcp.inflight.enable` man:sysctl[8] variable to `1`.
-This instructs the system to attempt to calculate the bandwidth delay product for each connection and limit the amount of data queued to the network to just the amount required to maintain optimum throughput.
-
-This feature is useful when serving data over modems, Gigabit Ethernet, high speed `WAN` links, or any other link with a high bandwidth delay product, especially when also using window scaling or when a large send window has been configured.
-When enabling this option, also set `net.inet.tcp.inflight.debug` to `0` to disable debugging.
-For production use, setting `net.inet.tcp.inflight.min` to at least `6144` may be beneficial.
-Setting high minimums may effectively disable bandwidth limiting, depending on the link.
-The limiting feature reduces the amount of data built up in intermediate route and switch packet queues and reduces the amount of data built up in the local host's interface queue.
-With fewer queued packets, interactive connections, especially over slow modems, will operate with lower _Round Trip Times_.
-This feature only effects server side data transmission such as uploading.
-It has no effect on data reception or downloading.
-
-Adjusting `net.inet.tcp.inflight.stab` is _not_ recommended.
-This parameter defaults to `20`, representing 2 maximal packets added to the bandwidth delay product window calculation.
-The additional window is required to stabilize the algorithm and improve responsiveness to changing conditions, but it can also result in higher man:ping[8] times over slow links, though still much lower than without the inflight algorithm.
-In such cases, try reducing this parameter to `15`, `10`, or `5` and reducing `net.inet.tcp.inflight.min` to a value such as `3500` to get the desired effect.
-Reducing these parameters should be done as a last resort only.
-
=== Virtual Memory
==== `kern.maxvnodes`
diff --git a/documentation/content/en/books/handbook/cutting-edge/_index.adoc b/documentation/content/en/books/handbook/cutting-edge/_index.adoc
index 3b1723044b..2dc1343ef9 100644
--- a/documentation/content/en/books/handbook/cutting-edge/_index.adoc
+++ b/documentation/content/en/books/handbook/cutting-edge/_index.adoc
@@ -92,7 +92,7 @@ Release announcements are available from https://www.FreeBSD.org/releases/[https
[NOTE]
====
-If a `crontab` utilizing the features of man:freebsd-update[8] exists, it must be disabled before upgrading the operating system.
+If a man:crontab[5] utilizing the features of man:freebsd-update[8] exists, it must be disabled before upgrading the operating system.
====
This section describes the configuration file used by `freebsd-update`, demonstrates how to apply a security patch and how to upgrade to a minor or major operating system release, and discusses some of the considerations when upgrading the operating system.
@@ -176,7 +176,7 @@ Effectively, `freebsd-update` will attempt to update every file which belongs to
[[freebsdupdate-security-patches]]
=== Applying Security Patches
-The process of applying FreeBSD security patches has been simplified, allowing an administrator to keep a system fully patched using `freebsd-update`.
+The process of applying FreeBSD security patches has been simplified, allowing an administrator to keep a system fully patched using `freebsd-update`.
More information about FreeBSD security advisories can be found in crossref:security[security-advisories,"FreeBSD Security Advisories"].
FreeBSD security patches may be downloaded and installed using the following commands.
@@ -195,7 +195,8 @@ If the patch was applied to any running binaries, the affected applications shou
[NOTE]
====
Usually, the user needs to be prepared to reboot the system.
-To know if a reboot is required by a kernel update, execute the commands `freebsd-version -k` and `uname -r` and if it differs a reboot is required.
+To know if the system requires a reboot due to a kernel update, execute the commands `freebsd-version -k` and `uname -r`.
+Reboot the system if the outputs differ.
====
The system can be configured to automatically check for updates once every day by adding this entry to [.filename]#/etc/crontab#:
@@ -407,7 +408,7 @@ After a major version upgrade, all installed packages and ports need to be upgra
Packages can be upgraded using `pkg upgrade`.
To upgrade installed ports, use a utility such as package:ports-mgmt/portmaster[].
-A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased.
+A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased.
This is required because of the ABI version change when upgrading between major versions of FreeBSD.
The forced upgrade can be accomplished by performing:
@@ -423,7 +424,7 @@ A rebuild of all installed applications can be accomplished with this command:
# portmaster -af
....
-This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens.
+This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens.
To prevent this behavior, and use only the default options, include `-G` in the above command.
Once the software upgrades are complete,
@@ -482,6 +483,11 @@ For example, [.filename]#/etc/passwd# will be modified if users have been added
Kernel modules may differ as `freebsd-update` may have updated them.
To exclude specific files or directories, add them to the `IDSIgnorePaths` option in [.filename]#/etc/freebsd-update.conf#.
+[[updating-bootcode]]
+== Updating Bootcode
+
+The following manuals describe the upgrade process of bootcode and boot loaders: man:gpart[8], man:gptboot[8], man:gptzfsboot[8], and man:loader.efi[8].
+
[[updating-upgrading-documentation]]
== Updating the Documentation Set
@@ -541,7 +547,7 @@ FreeBSD-CURRENT is the "bleeding edge" of FreeBSD development and FreeBSD-CURREN
Less technical users who wish to track a development branch should track FreeBSD-STABLE instead.
FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release.
-While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable.
+While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable.
These problems are resolved as quickly as possible, but whether or not FreeBSD-CURRENT brings disaster or new functionality can be a matter of when the source code was synced.
FreeBSD-CURRENT is made available for three primary interest groups:
@@ -597,7 +603,7 @@ To join these lists, go to {mailing-lists}, click on the list to subscribe to, a
In order to track changes for the whole source tree, subscribe to {dev-commits-src-all}.
. To install a new FreeBSD-STABLE system, install the most recent FreeBSD-STABLE release from the crossref:mirrors[mirrors,FreeBSD mirror sites] or use a monthly snapshot built from FreeBSD-STABLE. Refer to link:https://www.FreeBSD.org/snapshots/[www.freebsd.org/snapshots] for more information about snapshots.
+
-To compile or upgrade to an existing FreeBSD system to FreeBSD-STABLE, use `git` to check out the source for the desired branch.
+To compile or upgrade an existing FreeBSD system to FreeBSD-STABLE, use `git` to check out the source for the desired branch.
Branch names, such as `stable/9`, are listed at link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng].
. Before compiling or upgrading to FreeBSD-STABLE , read [.filename]#/usr/src/Makefile# carefully and follow the instructions in <<makeworld>>. Read the {freebsd-stable} and [.filename]#/usr/src/UPDATING# to keep up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release.
@@ -690,7 +696,7 @@ check /usr/src/UPDATING <.>
<.> Reboot the system to the new kernel.
-<.> Update and merge configuraton files in [.filename]#/etc/# required before installworld.
+<.> Update and merge configuration files in [.filename]#/etc/# required before installworld.
<.> Go to the source directory.
@@ -740,7 +746,7 @@ If the output says `fatal: not a git repository`, the files there are missing or
A new checkout of the source is required.
[[updating-src-obtaining-src-repopath]]
-.FreeBSD Versions and Repository Branchs
+.FreeBSD Versions and Repository Branches
[cols="10%,10%,80%", options="header"]
|===
| uname -r Output
diff --git a/documentation/content/en/books/handbook/disks/_index.adoc b/documentation/content/en/books/handbook/disks/_index.adoc
index 56eae6042f..20272d58bb 100644
--- a/documentation/content/en/books/handbook/disks/_index.adoc
+++ b/documentation/content/en/books/handbook/disks/_index.adoc
@@ -670,7 +670,7 @@ When used with `-R`, it produces a file system image that is identical to the sp
The last option of general use is `-b`.
This is used to specify the location of a boot image for use in producing an "El Torito" bootable CD.
This option takes an argument which is the path to a boot image from the top of the tree being written to the CD.
-By default, `mkisofs` creates an ISO image in "floppy disk emulation" mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size.
+By default, `mkisofs` creates an ISO image in "floppy disk emulation" mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size.
Some boot loaders, like the one used by the FreeBSD distribution media, do not use emulation mode.
In this case, `-no-emul-boot` should be used.
So, if [.filename]#/tmp/myboot# holds a bootable FreeBSD system with the boot image in [.filename]#/tmp/myboot/boot/cdboot#, this command would produce [.filename]#/tmp/bootable.iso#:
@@ -877,7 +877,7 @@ To force the write speed, use `-speed=`. Refer to man:growisofs[1] for example u
====
In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid file system must be created by passing `-udf -iso-level 3` to man:mkisofs[8] and all related programs, such as man:growisofs[1].
This is required only when creating an ISO image file or when writing files directly to a disk.
-Since a disk created this way must be mounted as an UDF file system with man:mount_udf[8], it will be usable only on an UDF aware operating system.
+Since a disk created this way must be mounted as an UDF file system with man:mount_udf[8], it will be usable only on an UDF aware operating system.
Otherwise it will look as if it contains corrupted files.
To create this type of ISO file:
@@ -1303,7 +1303,7 @@ When creating a backup file, make sure that the backup is not saved to the same
====
To restore the entire backup, `cd` into the directory to restore into and specify the name of the backup.
-Note that this will overwrite any newer versions of files in the restore directory.
+Note that this will overwrite any newer versions of files in the restore directory.
When in doubt, restore to a temporary directory or specify the name of the file within the backup to restore.
.Restoring Up the Current Directory with `tar`
@@ -1355,7 +1355,7 @@ While tape technology has continued to evolve, modern backup systems tend to com
FreeBSD supports any tape drive that uses SCSI, such as LTO or DAT.
There is limited support for SATA and USB tape drives.
-For SCSI tape devices, FreeBSD uses the man:sa[4] driver and the [.filename]#/dev/sa0#, [.filename]#/dev/nsa0#, and [.filename]#/dev/esa0# devices.
+For SCSI tape devices, FreeBSD uses the man:sa[4] driver and the [.filename]#/dev/sa0#, [.filename]#/dev/nsa0#, and [.filename]#/dev/esa0# devices.
The physical device name is [.filename]#/dev/sa0#. When [.filename]#/dev/nsa0# is used, the backup application will not rewind the tape after writing a file, which allows writing more than one file to a tape.
Using [.filename]#/dev/esa0# ejects the tape after the device is closed.
@@ -1557,7 +1557,7 @@ For more details about `mdmfs`, refer to man:mdmfs[8].
FreeBSD offers a feature in conjunction with crossref:config[soft-updates,Soft Updates]: file system snapshots.
UFS snapshots allow a user to create images of specified file systems, and treat them as a file.
-Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system.
+Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system.
Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots.
When a snapshot is no longer required, it can be removed using man:rm[1].
While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks.
@@ -1616,7 +1616,7 @@ For more information about `softupdates` and file system snapshots, including te
[[quotas]]
== Disk Quotas
-Disk quotas can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis.
+Disk quotas can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis.
This prevents one user or group of users from consuming all of the available disk space.
This section describes how to configure disk quotas for the UFS file system.
@@ -1804,7 +1804,7 @@ It first demonstrates the process using `gbde` and then demonstrates the same ex
=== Disk Encryption with gbde
-The objective of the man:gbde[4] facility is to provide a formidable challenge for an attacker to gain access to the contents of a _cold_ storage device.
+The objective of the man:gbde[4] facility is to provide a formidable challenge for an attacker to gain access to the contents of a _cold_ storage device.
However, if the computer is compromised while up and running and the storage device is actively attached, or the attacker has access to a valid passphrase, it offers no protection to the contents of the storage device.
Thus, it is important to provide physical security while the system is running and to protect the passphrase used by the encryption mechanism.
@@ -2204,7 +2204,7 @@ Device 1K-blocks Used Avail Capacity
[[disks-hast]]
== Highly Available Storage (HAST)
-High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments.
+High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments.
In FreeBSD, the Highly Available STorage (HAST) framework allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network.
HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD(R) storage system used in the GNU/Linux(R) platform.
In combination with other high-availability features of FreeBSD like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures.
@@ -2233,7 +2233,7 @@ The HAST project was sponsored by The FreeBSD Foundation with support from http:
=== HAST Operation
-HAST provides synchronous block-level replication between two physical machines: the _primary_ nodeand the _secondary_ node.
+HAST provides synchronous block-level replication between two physical machines: the _primary_ node and the _secondary_ node.
These two machines together are referred to as a cluster.
Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time.
@@ -2281,7 +2281,7 @@ The nodes will be called `hasta`, with an IP address of `172.16.0.1`, and `hastb
Both nodes will have a dedicated hard drive [.filename]#/dev/ad6# of the same size for HAST operation.
The HAST pool, sometimes referred to as a resource or the GEOM provider in [.filename]#/dev/hast/#, will be called `test`.
-Configuration of HAST is done using [.filename]#/etc/hast.conf#.
+Configuration of HAST is done using [.filename]#/etc/hast.conf#.
This file should be identical on both nodes.
The simplest configuration is:
diff --git a/documentation/content/en/books/handbook/eresources/_index.adoc b/documentation/content/en/books/handbook/eresources/_index.adoc
index 45cfd8b55c..a8a14644e1 100644
--- a/documentation/content/en/books/handbook/eresources/_index.adoc
+++ b/documentation/content/en/books/handbook/eresources/_index.adoc
@@ -54,13 +54,22 @@ Electronic resources are the best, if not often the only, way to stay informed o
Since FreeBSD is a volunteer effort, the user community itself also generally serves as a "technical support department" of sorts, with electronic mail, web forums, and USENET news being the most effective way of reaching that community.
The most important points of contact with the FreeBSD user community are outlined below.
+There is a possibly more up to date list on the link:https://wiki.freebsd.org/Community[community portal on the FreeBSD Wiki].
Please send other resources not mentioned here to the {freebsd-doc} so that they may also be included.
[[eresources-www]]
== Websites
-* https://forums.FreeBSD.org/[The FreeBSD Forums] provide a web based discussion forum for FreeBSD questions and technical discussion.
-* The http://www.youtube.com/bsdconferences[BSDConferences YouTube Channel] provides a collection of high quality videos from BSD conferences around the world. This is a great way to watch key developers give presentations about new work in FreeBSD.
+* The link:https://forums.FreeBSD.org/[FreeBSD Forums] provide a web based discussion forum for FreeBSD questions and technical discussion.
+* The link:https://wiki.FreeBSD.org/[FreeBSD Wiki] provides various bits of information that hadn't yet made it into the Handbook.
+* The link:https://docs.FreeBSD.org/[FreeBSD Documentation website] doesn't provide just the Users's Handbook; there are other handbooks and articles that are worth a read.
+* The link:https://freebsdfoundation.org/our-work/journal/browser-based-edition/[FreeBSD Journal] is a free, professionally-edited, bi-monthly technical magazine released by link:https://freebsdfoundation.org[FreeBSD Foundation].
+* The link:http://www.youtube.com/bsdconferences[BSDConferences YouTube Channel] provides a collection of high quality videos from BSD conferences around the world. This is a great way to watch key developers give presentations about new work in FreeBSD.
+* link:https://www.freebsd.org/status/[FreeBSD Status Reports] are released every three months and track progress of FreeBSD development.
+* There's a link:https://www.reddit.com/r/freebsd/[FreeBSD-focused Reddit group] at r/freebsd.
+* link:https://superuser.com/questions/tagged/freebsd[Super User] and link:https://serverfault.com/questions/tagged/freebsd[Server Fault], the Stack Exchange services for system administrators.
+* link:https://wiki.freebsd.org/Discord[FreeBSD Discord server], a communications and community-building service, where FreeBSD community members can socialise, obtain support or support others, learn, contribute, collaborate, and stay up to date with all things FreeBSD-related.
+* link:https://wiki.freebsd.org/IRC/Channels[IRC channels], a widely implemented, technically mature, open standard text chat.
[[eresources-mail]]
== Mailing Lists
@@ -84,7 +93,7 @@ When in doubt about what list to post a question to, see extref:{freebsd-questio
Before posting to any list, please learn about how to best use the mailing lists, such as how to help avoid frequently-repeated discussions, by reading the extref:{mailing-list-faq}[Mailing List Frequently Asked Questions] (FAQ) document.
-Archives are kept for all of the mailing lists and can be searched using the https://www.FreeBSD.org/search/[FreeBSD World Wide Web server].
+Archives are kept for all of the mailing lists and can be searched using the link:https://www.FreeBSD.org/search/[FreeBSD World Wide Web server].
The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question.
Note that this also means that messages sent to FreeBSD mailing lists are archived in perpetuity.
When protecting privacy is a concern, consider using a disposable secondary email address and posting only public information.
@@ -100,6 +109,9 @@ _General lists:_ The following are general lists which anyone is free (and encou
| List
| Purpose
+|link:{freebsd-accessibility-url}[freebsd-accessibility]
+|FreeBSD accessibility discussions
+
|link:{freebsd-advocacy-url}[freebsd-advocacy]
|FreeBSD Evangelism
@@ -662,7 +674,7 @@ link:{freebsd-bugs-url}[freebsd-bugs]::
_Bug reports_
+
This is the mailing list for reporting bugs in FreeBSD.
-Whenever possible, bugs should be submitted using the https://bugs.freebsd.org/bugzilla/enter_bug.cgi[web interface] to it.
+Whenever possible, bugs should be submitted using the link:https://bugs.freebsd.org/bugzilla/enter_bug.cgi[web interface].
link:{freebsd-chat-url}[freebsd-chat]::
_Non technical items related to the FreeBSD community_
@@ -1013,7 +1025,7 @@ _Discussions about the use of FreeBSD-STABLE_
This is the mailing list for users of FreeBSD-STABLE.
"STABLE" is the branch where development continues after a RELEASE, including bug fixes and new features.
The ABI is kept stable for binary compatibility.
-It includes warnings about new features coming out in -STABLE that will affect the users, and instructions on steps that must be taken to remain -STABLE.
+It includes warnings about new features coming out in -STABLE that will affect the users, and instructions on steps that must be taken to remain -STABLE.
Anyone running "STABLE" should subscribe to this list.
This is a technical mailing list for which strictly technical content is expected.
@@ -1081,11 +1093,6 @@ _FreeBSD Work-In-Progress Status_
This mailing list can be used by developers to announce the creation and progress of FreeBSD related work.
Messages will be moderated. It is suggested to send the message "To:" a more topical FreeBSD list and only "BCC:" this list.
This way the WIP can also be discussed on the topical list, as no discussion is allowed on this list.
-+
-Look inside the archives for examples of suitable messages.
-+
-An editorial digest of the messages to this list might be posted to the FreeBSD website every few months as part of the Status Reports footnote:[https://www.freebsd.org/news/status/].
-Past reports are archived.
link:{freebsd-wireless-url}[freebsd-wireless]::
_Discussions of 802.11 stack, tools device driver development_
@@ -1170,143 +1177,3 @@ In addition to two FreeBSD specific newsgroups, there are many others in which F
=== X Window System
* link:news:comp.windows.x[comp.windows.x]
-
-[[eresources-web]]
-== Official Mirrors
-
-<<central-mirrors, {central}>>, <<armenia-mirrors, {mirrors-armenia}>>, <<australia-mirrors, {mirrors-australia}>>, <<austria-mirrors, {mirrors-austria}>>, <<czech-republic-mirrors, {mirrors-czech}>>, <<denmark-mirrors, {mirrors-denmark}>>, <<finland-mirrors, {mirrors-finland}>>, <<france-mirrors, {mirrors-france}>>, <<germany-mirrors, {mirrors-germany}>>, <<hong-kong-mirrors, {mirrors-hongkong}>>, <<ireland-mirrors, {mirrors-ireland}>>, <<japan-mirrors, {mirrors-japan}>>, <<latvia-mirrors, {mirrors-latvia}>>, <<lithuania-mirrors, {mirrors-lithuania}>>, <<netherlands-mirrors, {mirrors-netherlands}>>, <<norway-mirrors, {mirrors-norway}>>, <<russia-mirrors, {mirrors-russia}>>, <<slovenia-mirrors, {mirrors-slovenia}>>, <<south-africa-mirrors, {mirrors-south-africa}>>, <<spain-mirrors, {mirrors-spain}>>, <<sweden-mirrors, {mirrors-sweden}>>, <<switzerland-mirrors, {mirrors-switzerland}>>, <<taiwan-mirrors, {mirrors-taiwan}>>, <<uk-mirrors, {mirrors-uk}>>, <<usa-mirrors, {mirrors-us}>>.
-
-[[central-mirrors]]
-*{central}*
-
-* {central-www}
-
-[[armenia-mirrors]]
-*{mirrors-armenia}*
-
-* {mirrors-armenia-www-httpv6} (IPv6)
-
-[[australia-mirrors]]
-*{mirrors-australia}*
-
-* {mirrors-australia-www-http}
-* {mirrors-australia-www2-http}
-
-[[austria-mirrors]]
-*{mirrors-austria}*
-
-* {mirrors-armenia-www-httpv6} (IPv6)
-
-[[czech-republic-mirrors]]
-*{mirrors-czech}*
-
-* {mirrors-czech-www-httpv6} (IPv6)
-
-[[denmark-mirrors]]
-*{mirrors-denmark}*
-
-* {mirrors-denmark-www-httpv6} (IPv6)
-
-[[finland-mirrors]]
-*{mirrors-finland}*
-
-* {mirrors-finland-www-http}
-
-[[france-mirrors]]
-*{mirrors-france}*
-
-* {mirrors-france-www-http}
-
-[[germany-mirrors]]
-*{mirrors-germany}*
-
-* {mirrors-germany-www-http}
-
-[[hong-kong-mirrors]]
-*{mirrors-hongkong}*
-
-* {mirrors-hongkong-www}
-
-[[ireland-mirrors]]
-*{mirrors-ireland}*
-
-* {mirrors-ireland-www}
-
-[[japan-mirrors]]
-*{mirrors-japan}*
-
-* {mirrors-japan-www-httpv6} (IPv6)
-
-[[latvia-mirrors]]
-*{mirrors-latvia}*
-
-* {mirrors-latvia-www}
-
-[[lithuania-mirrors]]
-*{mirrors-lithuania}*
-
-* {mirrors-lithuania-www}
-
-[[netherlands-mirrors]]
-*{mirrors-netherlands}*
-
-* {mirrors-netherlands-www}
-
-[[norway-mirrors]]
-*{mirrors-norway}*
-
-* {mirrors-norway-www}
-
-[[russia-mirrors]]
-*{mirrors-russia}*
-
-* {mirrors-russia-www-httpv6} (IPv6)
-
-[[slovenia-mirrors]]
-*{mirrors-slovenia}*
-
-* {mirrors-slovenia-www}
-
-[[south-africa-mirrors]]
-*{mirrors-south-africa}*
-
-* {mirrors-south-africa-www}
-
-[[spain-mirrors]]
-*{mirrors-spain}*
-
-* {mirrors-spain-www}
-* {mirrors-spain-www2}
-
-[[sweden-mirrors]]
-*{mirrors-sweden}*
-
-* {mirrors-sweden-www}
-
-[[switzerland-mirrors]]
-*{mirrors-switzerland}*
-
-* {mirrors-switzerland-www-httpv6} (IPv6)
-* {mirrors-switzerland-www2-httpv6} (IPv6)
-
-[[taiwan-mirrors]]
-*{mirrors-taiwan}*
-
-* {mirrors-taiwan-www}
-* {mirrors-taiwan-www2}
-* {mirrors-taiwan-www4}
-* {mirrors-taiwan-www5-httpv6} (IPv6)
-
-[[uk-mirrors]]
-*{mirrors-uk}*
-
-* {mirrors-uk-www}
-* {mirrors-uk-www3}
-
-[[usa-mirrors]]
-*{mirrors-us}*
-
-* {mirrors-us-www5-httpv6} (IPv6)
-
-:sectnums:
-:sectnumlevels: 6
diff --git a/documentation/content/en/books/handbook/firewalls/_index.adoc b/documentation/content/en/books/handbook/firewalls/_index.adoc
index 6ebfa03a6a..0d77039b67 100644
--- a/documentation/content/en/books/handbook/firewalls/_index.adoc
+++ b/documentation/content/en/books/handbook/firewalls/_index.adoc
@@ -93,7 +93,7 @@ For a good introduction, refer to http://www.ipprimer.com[Daryl's TCP/IP Primer]
A ruleset contains a group of rules which pass or block packets based on the values contained in the packet.
The bi-directional exchange of packets between hosts comprises a session conversation.
-The firewall ruleset processes both the packets arriving from the public Internet, as well as the packets produced by the system as a response to them.
+The firewall ruleset processes both the packets arriving from the public Internet, as well as the packets produced by the system as a response to them.
Each TCP/IP service is predefined by its protocol and listening port.
Packets destined for a specific service originate from the source address using an unprivileged port and target the specific service port on the destination address.
All the above parameters can be used as selection criteria to create rules which will pass or block services.
@@ -488,7 +488,7 @@ Note the `quick` keyword in this rule.
Since the ruleset consists of several rules, it is important to understand the relationships between the rules in a ruleset.
Rules are evaluated from top to bottom, in the sequence they are written.
For each packet or connection evaluated by PF, _the last matching rule_ in the ruleset is the one which is applied.
-However, when a packet matches a rule which contains the `quick` keyword, the rule processing stops and the packet is treated according to that rule.
+However, when a packet matches a rule which contains the `quick` keyword, the rule processing stops and the packet is treated according to that rule.
This is very useful when an exception to the general rules is needed.
[[pftut-ftp]]
@@ -502,8 +502,8 @@ The most common points against using FTP include:
* The protocol demands the use of at least two TCP connections (control and data) on separate ports.
* When a session is established, data is communicated using randomly selected ports.
-All of these points present security challenges, even before considering any potential security weaknesses in client or server software.
-More secure alternatives for file transfer exist, such as man:sftp[1] or man:scp[1], which both feature authentication and data transfer over encrypted connections..
+All of these points present security challenges, even before considering any potential security weaknesses in client or server software.
+More secure alternatives for file transfer exist, such as man:sftp[1] or man:scp[1], which both feature authentication and data transfer over encrypted connections.
For those situations when FTP is required, PF provides redirection of FTP traffic to a small proxy program called man:ftp-proxy[8], which is included in the base system of FreeBSD.
The role of the proxy is to dynamically insert and delete rules in the ruleset, using a set of anchors, to correctly handle FTP traffic.
@@ -515,7 +515,12 @@ To enable the FTP proxy, add this line to [.filename]#/etc/rc.conf#:
ftpproxy_enable="YES"
....
-Then start the proxy by running `service ftp-proxy start`.
+Then start the proxy by running:
+
+[source,bash]
+....
+# service ftp-proxy start
+....
For a basic configuration, three elements need to be added to [.filename]#/etc/pf.conf#.
First, the anchors which the proxy will use to insert the rules it generates for the FTP sessions:
@@ -715,7 +720,7 @@ This is indicative of a brute force attack where somebody or some program is try
If external SSH access is needed for legitimate users, changing the default port used by SSH can offer some protection.
However, PF provides a more elegant solution.
-Pass rules can contain limits on what connecting hosts can do and violators can be banished to a table of addresses which are denied some or all access.
+Pass rules can contain limits on what connecting hosts can do and violators can be banished to a table of addresses which are denied some or all access.
It is even possible to drop all existing connections from machines which overreach the limits.
To configure this, create this table in the tables section of the ruleset:
@@ -1400,7 +1405,7 @@ $cmd 00999 deny log all from any to any
[[in-kernel-nat]]
=== In-kernel NAT
-FreeBSD's IPFW firewall has two implementations of NAT: the userland implementation man:natd[8], and the more recent in-kernel NAT implementation.
+FreeBSD's IPFW firewall has two implementations of NAT: the userland implementation man:natd[8], and the more recent in-kernel NAT implementation.
Both work in conjunction with IPFW to provide network address translation.
This can be used to provide an Internet Connection Sharing solution so that several internal computers can connect to the Internet using a single public IP address.
@@ -1453,7 +1458,7 @@ net.inet.tcp.tso="0"
A NAT instance will also be configured.
It is possible to have multiple NAT instances each with their own configuration.
For this example only one NAT instance is needed, NAT instance number 1.
-The configuration can take a few options such as: `if` which indicates the public interface, `same_ports` which takes care that alliased ports and local port numbers are mapped the same, `unreg_only` will result in only unregistered (private) address spaces to be processed by the NAT instance, and `reset` which will help to keep a functioning NAT instance even when the public IP address of the IPFW machine changes.
+The configuration can take a few options such as: `if` which indicates the public interface, `same_ports` which takes care that aliased ports and local port numbers are mapped the same, `unreg_only` will result in only unregistered (private) address spaces to be processed by the NAT instance, and `reset` which will help to keep a functioning NAT instance even when the public IP address of the IPFW machine changes.
For all possible options that can be passed to a single NAT instance configuration consult man:ipfw[8].
When configuring a stateful NATing firewall, it is necessary to allow translated packets to be reinjected in the firewall for further processing.
This can be achieved by disabling `one_pass` behavior at the start of the firewall script.
@@ -2079,10 +2084,10 @@ All the rules use `quick` and specify the appropriate port numbers and, where ap
# firewall, destined for the Internet.
# Allow outbound access to public DNS servers.
-# Replace x.x.x. with address listed in /etc/resolv.conf.
+# Replace x.x.x.x with address listed in /etc/resolv.conf.
# Repeat for each DNS server.
-pass out quick on dc0 proto tcp from any to x.x.x. port = 53 flags S keep state
-pass out quick on dc0 proto udp from any to xxx port = 53 keep state
+pass out quick on dc0 proto tcp from any to x.x.x.x port = 53 flags S keep state
+pass out quick on dc0 proto udp from any to x.x.x.x port = 53 keep state
# Allow access to ISP's specified DHCP server for cable or DSL networks.
# Use the first rule, then check log for the IP address of DHCP server.
@@ -2320,7 +2325,7 @@ To turn verbose mode on and display information relating to rule processing and
=== Viewing IPF Statistics
-IPF includes man:ipfstat[8] which can be used to retrieve and display statistics which are gathered as packets match rules as they go through the firewall.
+IPF includes man:ipfstat[8] which can be used to retrieve and display statistics which are gathered as packets match rules as they go through the firewall.
Statistics are accumulated since the firewall was last started or since the last time they were reset to zero using `ipf -Z`.
The default `ipfstat` output looks like this:
@@ -2509,7 +2514,7 @@ The syntax for the location field is as follows:
[address|interface][/mask][:port]
....
-Adressses can be specified as IPv4 in numeric format or IPv6 in square brackets.
+Addresses can be specified as IPv4 in numeric format or IPv6 in square brackets.
An interface name like `_em0_` can also be used.
The socket type is defined by the second field.
@@ -2680,6 +2685,6 @@ After identifying the address to be unblocked from the list, the following comma
# pfctl -a blacklistd/22 -t port22 -T delete 213.0.123.128/25
....
-The address is now removed from PF, but will still show up in the blacklistctl list, since it does not know about any changes made in PF.
-The entry in blacklistd's database will eventually expire and be removed from its output eventually.
+The address is now removed from PF, but will still show up in the blacklistctl list, since it does not know about any changes made in PF.
+The entry in blacklistd's database will eventually expire and be removed from its output.
The entry will be added again if the host is matching one of the block rules in blacklistd again.
diff --git a/documentation/content/en/books/handbook/geom/_index.adoc b/documentation/content/en/books/handbook/geom/_index.adoc
index d0667b683f..01a26d9ae5 100644
--- a/documentation/content/en/books/handbook/geom/_index.adoc
+++ b/documentation/content/en/books/handbook/geom/_index.adoc
@@ -247,7 +247,7 @@ Create the mirror with the two new drives:
After the mirror has been started, this device name appears in [.filename]#/dev/mirror/#.
MBR and bsdlabel partition tables can now be created on the mirror with man:gpart[8].
-This example uses a traditional file system layout, with partitions for [.filename]#/#, swap, [.filename]#/var#, [.filename]#/tmp#, and [.filename]#/usr#.
+This example uses a traditional file system layout, with partitions for [.filename]#/#, swap, [.filename]#/var#, [.filename]#/tmp#, and [.filename]#/usr#.
A single [.filename]#/# and a swap partition will also work.
Partitions on the mirror do not have to be the same size as those on the existing disk, but they must be large enough to hold all the data already present on [.filename]#ada0#.
@@ -555,7 +555,7 @@ Each file system dumped with `dump -L` will create a snapshot first, which can t
....
Restart the system, booting from [.filename]#ada1#.
-If everything is working, the system will boot from [.filename]#mirror/gm0#, which now contains the same data as [.filename]#ada0# had previously.
+If everything is working, the system will boot from [.filename]#mirror/gm0#, which now contains the same data as [.filename]#ada0# had previously.
See <<gmirror-troubleshooting>> if there are problems booting.
At this point, the mirror still consists of only the single [.filename]#ada1# disk.
@@ -621,7 +621,7 @@ Manual root filesystem specification:
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
- eg. ufs:/dev/da0s1a
+ e.g. ufs:/dev/da0s1a
zfs:tank
cd9660:/dev/acd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)
@@ -1297,7 +1297,7 @@ For instance, if [.filename]#ad4s1# and [.filename]#ad4s2# are both slices, then
Journaling may also be enabled on current file systems by using `tunefs`.
However, _always_ make a backup before attempting to alter an existing file system.
-In most cases, `gjournal` will fail if it is unable to create the journal, but this does not protect against data loss incurred as a result of misusing `tunefs`.
+In most cases, `gjournal` will fail if it is unable to create the journal, but this does not protect against data loss incurred as a result of misusing `tunefs`.
Refer to man:gjournal[8] and man:tunefs[8] for more information about these commands.
It is possible to journal the boot disk of a FreeBSD system.
diff --git a/documentation/content/en/books/handbook/introduction.adoc b/documentation/content/en/books/handbook/introduction.adoc
new file mode 100644
index 0000000000..f99c4ff117
--- /dev/null
+++ b/documentation/content/en/books/handbook/introduction.adoc
@@ -0,0 +1,12 @@
+[.abstract-title]
+Abstract
+
+Welcome to FreeBSD! This handbook covers the installation and day to day use of _FreeBSD {rel131-current}-RELEASE_ and _FreeBSD {rel123-current}-RELEASE_.
+This book is the result of ongoing work by many individuals.
+Some sections might be outdated.
+Those interested in helping to update and expand this document should send email to the {freebsd-doc}.
+
+The latest version of this book is available from the https://www.FreeBSD.org/[FreeBSD web site].
+Previous versions can be obtained from https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/].
+The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD download server] or one of the numerous link:./mirrors#mirrors[mirror sites].
+Searches can be performed on the handbook and other documents on the link:https://www.FreeBSD.org/search/[search page].
diff --git a/documentation/content/en/books/handbook/introduction/_index.adoc b/documentation/content/en/books/handbook/introduction/_index.adoc
index 976fb7f174..77d0740485 100644
--- a/documentation/content/en/books/handbook/introduction/_index.adoc
+++ b/documentation/content/en/books/handbook/introduction/_index.adoc
@@ -113,47 +113,47 @@ Please see crossref:mirrors[mirrors, Obtaining FreeBSD] for more information abo
[[introduction-nutshell-users]]
=== Who Uses FreeBSD?
-FreeBSD has been known for its web serving capabilities - sites that run on FreeBSD include https://news.ycombinator.com/[Hacker News], http://www.netcraft.com/[Netcraft], http://www.163.com/[NetEase], https://signup.netflix.com/openconnect[Netflix], http://www.sina.com/[Sina], http://www.sony.co.jp/[Sony Japan], http://www.rambler.ru/[Rambler], http://www.yahoo.com/[Yahoo!], and http://www.yandex.ru/[Yandex].
+FreeBSD has been known for its web serving capabilities - sites that run on FreeBSD include link:https://news.ycombinator.com/[Hacker News], link:http://www.netcraft.com/[Netcraft], link:http://www.163.com/[NetEase], link:https://signup.netflix.com/openconnect[Netflix], link:http://www.sina.com/[Sina], link:http://www.sony.co.jp/[Sony Japan], link:http://www.rambler.ru/[Rambler], link:http://www.yahoo.com/[Yahoo!], and link:http://www.yandex.ru/[Yandex].
FreeBSD's advanced features, proven security, predictable release cycle, and permissive license have led to its use as a platform for building many commercial and open source appliances, devices, and products.
Many of the world's largest IT companies use FreeBSD:
-* http://www.apache.org/[Apache] - The Apache Software Foundation runs most of its public facing infrastructure, including possibly one of the largest SVN repositories in the world with over 1.4 million commits, on FreeBSD.
-* http://www.apple.com/[Apple] - OS X borrows heavily from FreeBSD for the network stack, virtual file system, and many userland components. Apple iOS also contains elements borrowed from FreeBSD.
-* http://www.cisco.com/[Cisco] - IronPort network security and anti-spam appliances run a modified FreeBSD kernel.
-* http://www.citrix.com/[Citrix] - The NetScaler line of security appliances provide layer 4-7 load balancing, content caching, application firewall, secure VPN, and mobile cloud network access, along with the power of a FreeBSD shell.
-* https://www.emc.com/isilon[Dell EMC Isilon] - Isilon's enterprise storage appliances are based on FreeBSD. The extremely liberal FreeBSD license allowed Isilon to integrate their intellectual property throughout the kernel and focus on building their product instead of an operating system.
-* http://www.quest.com/KACE[Quest KACE] - The KACE system management appliances run FreeBSD because of its reliability, scalability, and the community that supports its continued development.
-* http://www.ixsystems.com/[iXsystems] - The TrueNAS line of unified storage appliances is based on FreeBSD.
-* http://www.juniper.net/[Juniper] - The JunOS operating system that powers all Juniper networking gear (including routers, switches, security, and networking appliances) is based on FreeBSD. Juniper is one of many vendors that showcases the symbiotic relationship between the project and vendors of commercial products. Improvements generated at Juniper are upstreamed into FreeBSD to reduce the complexity of integrating new features from FreeBSD back into JunOS in the future.
-* http://www.mcafee.com/[McAfee] - SecurOS, the basis of McAfee enterprise firewall products including Sidewinder is based on FreeBSD.
-* http://www.netapp.com/[NetApp] - The Data ONTAP GX line of storage appliances are based on FreeBSD. In addition, NetApp has contributed back many features, including the new BSD licensed hypervisor, bhyve.
-* http://www.netflix.com/[Netflix] - The OpenConnect appliance that Netflix uses to stream movies to its customers is based on FreeBSD. Netflix has made extensive contributions to the codebase and works to maintain a zero delta from mainline FreeBSD. Netflix OpenConnect appliances are responsible for delivering more than 32% of all Internet traffic in North America.
-* http://www.sandvine.com/[Sandvine] - Sandvine uses FreeBSD as the basis of their high performance real-time network processing platforms that make up their intelligent network policy control products.
-* http://www.sony.com/[Sony] - The PlayStation 4 gaming console runs a modified version of FreeBSD.
-* http://www.sophos.com/[Sophos] - The Sophos Email Appliance product is based on a hardened FreeBSD and scans inbound mail for spam and viruses, while also monitoring outbound mail for malware as well as the accidental loss of sensitive information.
-* http://www.spectralogic.com/[Spectra Logic] - The nTier line of archive grade storage appliances run FreeBSD and OpenZFS.
-* https://www.stormshield.com[Stormshield] - Stormshield Network Security appliances are based on a hardened version of FreeBSD. The BSD license allows them to integrate their own intellectual property with the system while returning a great deal of interesting development to the community.
-* http://www.weather.com/[The Weather Channel] - The IntelliStar appliance that is installed at each local cable provider's headend and is responsible for injecting local weather forecasts into the cable TV network's programming runs FreeBSD.
-* http://www.verisign.com/[Verisign] - Verisign is responsible for operating the .com and .net root domain registries as well as the accompanying DNS infrastructure. They rely on a number of different network operating systems including FreeBSD to ensure there is no common point of failure in their infrastructure.
-* http://www.voxer.com/[Voxer] - Voxer powers their mobile voice messaging platform with ZFS on FreeBSD. Voxer switched from a Solaris derivative to FreeBSD because of its superior documentation, larger and more active community, and more developer friendly environment. In addition to critical features like ZFS and DTrace, FreeBSD also offers TRIM support for ZFS.
-* https://fudosecurity.com/en/[Fudo Security] - The FUDO security appliance allows enterprises to monitor, control, record, and audit contractors and administrators who work on their systems. Based on all of the best security features of FreeBSD including ZFS, GELI, Capsicum, HAST, and auditdistd.
+* link:http://www.apache.org/[Apache] - The Apache Software Foundation runs most of its public facing infrastructure, including possibly one of the largest SVN repositories in the world with over 1.4 million commits, on FreeBSD.
+* link:http://www.apple.com/[Apple] - OS X borrows heavily from FreeBSD for the network stack, virtual file system, and many userland components. Apple iOS also contains elements borrowed from FreeBSD.
+* link:http://www.cisco.com/[Cisco] - IronPort network security and anti-spam appliances run a modified FreeBSD kernel.
+* link:http://www.citrix.com/[Citrix] - The NetScaler line of security appliances provide layer 4-7 load balancing, content caching, application firewall, secure VPN, and mobile cloud network access, along with the power of a FreeBSD shell.
+* link:https://www.emc.com/isilon[Dell EMC Isilon] - Isilon's enterprise storage appliances are based on FreeBSD. The extremely liberal FreeBSD license allowed Isilon to integrate their intellectual property throughout the kernel and focus on building their product instead of an operating system.
+* link:http://www.quest.com/KACE[Quest KACE] - The KACE system management appliances run FreeBSD because of its reliability, scalability, and the community that supports its continued development.
+* link:http://www.ixsystems.com/[iXsystems] - The TrueNAS line of unified storage appliances is based on FreeBSD.
+* link:http://www.juniper.net/[Juniper] - The JunOS operating system that powers all Juniper networking gear (including routers, switches, and security and networking appliances) is based on FreeBSD. Juniper is one of many vendors that showcases the symbiotic relationship between the project and vendors of commercial products. Improvements generated at Juniper are upstreamed into FreeBSD to reduce the complexity of integrating new features from FreeBSD back into JunOS in the future.
+* link:http://www.mcafee.com/[McAfee] - SecurOS, the basis of McAfee enterprise firewall products including Sidewinder is based on FreeBSD.
+* link:http://www.netapp.com/[NetApp] - The Data ONTAP GX line of storage appliances are based on FreeBSD. In addition, NetApp has contributed back many features, including the new BSD licensed hypervisor, bhyve.
+* link:http://www.netflix.com/[Netflix] - The OpenConnect appliance that Netflix uses to stream movies to its customers is based on FreeBSD. Netflix has made extensive contributions to the codebase and works to maintain a zero delta from mainline FreeBSD. Netflix OpenConnect appliances are responsible for delivering more than 32% of all Internet traffic in North America.
+* link:http://www.sandvine.com/[Sandvine] - Sandvine uses FreeBSD as the basis of their high performance real-time network processing platforms that make up their intelligent network policy control products.
+* link:http://www.sony.com/[Sony] - The PlayStation Vita, PlayStation 4, and PlayStation 5 gaming consoles run a modified version of FreeBSD.
+* link:http://www.sophos.com/[Sophos] - The Sophos Email Appliance product is based on a hardened FreeBSD and scans inbound mail for spam and viruses, while also monitoring outbound mail for malware as well as the accidental loss of sensitive information.
+* link:http://www.spectralogic.com/[Spectra Logic] - The nTier line of archive grade storage appliances run FreeBSD and OpenZFS.
+* link:https://www.stormshield.com[Stormshield] - Stormshield Network Security appliances are based on a hardened version of FreeBSD. The BSD license allows them to integrate their own intellectual property with the system while returning a great deal of interesting development to the community.
+* link:http://www.weather.com/[The Weather Channel] - The IntelliStar appliance that is installed at each local cable provider's headend and is responsible for injecting local weather forecasts into the cable TV network's programming runs FreeBSD.
+* link:http://www.verisign.com/[Verisign] - Verisign is responsible for operating the .com and .net root domain registries as well as the accompanying DNS infrastructure. They rely on a number of different network operating systems including FreeBSD to ensure there is no common point of failure in their infrastructure.
+* link:http://www.voxer.com/[Voxer] - Voxer powers their mobile voice messaging platform with ZFS on FreeBSD. Voxer switched from a Solaris derivative to FreeBSD because of its superior documentation, larger and more active community, and more developer friendly environment. In addition to critical features like ZFS and DTrace, FreeBSD also offers TRIM support for ZFS.
+* link:https://fudosecurity.com/en/[Fudo Security] - The FUDO security appliance allows enterprises to monitor, control, record, and audit contractors and administrators who work on their systems. Based on all of the best security features of FreeBSD including ZFS, GELI, Capsicum, HAST, and auditdistd.
FreeBSD has also spawned a number of related open source projects:
-* http://bsdrp.net/[BSD Router] - A FreeBSD based replacement for large enterprise routers designed to run on standard PC hardware.
-* https://www.truenas.com/[TrueNAS] is a Network Attached Storage (NAS) software that shares and protects data from modern-day threats like ransomware and malware. TrueNAS makes it easy for users and client devices to access shared data through virtually any sharing protocol.
-* https://ghostbsd.org/[GhostBSD] - is derived from FreeBSD, uses the GTK environment to provide a beautiful looks and comfortable experience on the modern BSD platform offering a natural and native UNIX(R) work environment.
-* http://mfsbsd.vx.sk/[mfsBSD] - A toolkit for building a FreeBSD system image that runs entirely from memory.
-* https://xigmanas.com/[XigmaNAS] - A file server distribution based on FreeBSD with a PHP powered web interface.
-* http://www.opnsense.org/[OPNSense] - OPNsense is an open source, easy-to-use and easy-to-build FreeBSD based firewall and routing platform. OPNsense includes most of the features available in expensive commercial firewalls, and more in many cases. It brings the rich feature set of commercial offerings with the benefits of open and verifiable sources.
-* https://www.midnightbsd.org[MidnightBSD] - is a FreeBSD derived operating system developed with desktop users in mind. It includes all the software you'd expect for your daily tasks: mail, web browsing, word processing, gaming, and much more.
-* https://www.nomadbsd.org[NomadBSD] - is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or to test FreeBSD's hardware compatibility.
-* http://www.pfsense.org/[pfSense] - A firewall distribution based on FreeBSD with a huge array of features and extensive IPv6 support.
-* http://zrouter.org/[ZRouter] - An open source alternative firmware for embedded devices based on FreeBSD. Designed to replace the proprietary firmware on off-the-shelf routers.
+* link:http://bsdrp.net/[BSD Router] - A FreeBSD based replacement for large enterprise routers, designed to run on standard PC hardware.
+* link:https://www.truenas.com/[TrueNAS] is a Network Attached Storage (NAS) software that shares and protects data from modern-day threats like ransomware and malware. TrueNAS makes it easy for users and client devices to access shared data through virtually any sharing protocol.
+* link:https://ghostbsd.org/[GhostBSD] is derived from FreeBSD, uses the GTK environment to provide a beautiful look and comfortable experience on the modern BSD platform offering a natural and native UNIX(R) work environment.
+* link:http://mfsbsd.vx.sk/[mfsBSD] - A toolkit for building a FreeBSD system image that runs entirely from memory.
+* link:https://xigmanas.com/[XigmaNAS] - A file server distribution based on FreeBSD with a PHP powered web interface.
+* link:http://www.opnsense.org/[OPNSense] is an open source, easy-to-use and easy-to-build FreeBSD based firewall and routing platform. OPNsense includes most of the features available in expensive commercial firewalls, and more in many cases. It brings the rich feature set of commercial offerings with the benefits of open and verifiable sources.
+* link:https://www.midnightbsd.org[MidnightBSD] is a FreeBSD derived operating system developed with desktop users in mind. It includes all the software you'd expect for your daily tasks: mail, web browsing, word processing, gaming, and much more.
+* link:https://www.nomadbsd.org[NomadBSD] is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or to test FreeBSD's hardware compatibility.
+* link:http://www.pfsense.org/[pfSense] - A firewall distribution based on FreeBSD with a huge array of features and extensive IPv6 support.
+* link:http://zrouter.org/[ZRouter] - An open source alternative firmware for embedded devices based on FreeBSD. Designed to replace the proprietary firmware on off-the-shelf routers.
-A list of https://www.freebsdfoundation.org/about/testimonials/[testimonials from companies basing their products and services on FreeBSD] can be found at the FreeBSD Foundation website.
-Wikipedia also maintains a https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD[list of products based on FreeBSD].
+A list of link:https://www.freebsdfoundation.org/about/testimonials/[testimonials from companies basing their products and services on FreeBSD] can be found at the FreeBSD Foundation website.
+Wikipedia also maintains a link:https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD[list of products based on FreeBSD].
[[history]]
== About the FreeBSD Project
@@ -194,7 +194,7 @@ Despite being still more than a little rough around the edges, the release was a
Since that time, FreeBSD has made a series of releases each time improving the stability, speed, and feature set of the previous version.
-For now, long-term development projects continue to take place in the 10.X-CURRENT (trunk) branch, and snapshot releases of 10.X are continually made available from link:ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/[the snapshot server] as work progresses.
+For now, long-term development projects continue to take place in the {rel-head}-CURRENT (main) branch, and snapshot releases of {rel-head} are continually made available from link:https://download.freebsd.org/snapshots/[the snapshot server] as work progresses.
[[goals]]
=== FreeBSD Project Goals
@@ -210,31 +210,30 @@ Due to the additional complexities that can evolve in the commercial use of GPL
[[development]]
=== The FreeBSD Development Model
-The development of FreeBSD is a very open and flexible process, being literally built from the contributions of thousands of people around the world, as can be seen from our extref:{contributors}[list of contributors].
-FreeBSD's development infrastructure allow these thousands of contributors to collaborate over the Internet.
-We are constantly on the lookout for new developers and ideas, and those interested in becoming more closely involved with the project need simply contact us at the {freebsd-hackers}.
-The {freebsd-announce} is also available to those wishing to make other FreeBSD users aware of major areas of work.
+The development of FreeBSD is a extref:{dev-model}[very open and flexible process], being literally built from the contributions of thousands of people around the world, as can be seen from our extref:{contributors}[list of contributors].
+FreeBSD's development infrastructure allows these thousands of contributors to collaborate over the Internet.
+We are constantly on the lookout for new volunteers, and those interested in becoming more closely involved should consult the article on extref:{contributing}[Contributing to FreeBSD].
Useful things to know about the FreeBSD Project and its development process, whether working independently or in close cooperation:
The Git repositories[[development-cvs-repository]]::
-For several years, the central source tree for FreeBSD was maintained by http://www.nongnu.org/cvs/[CVS] (Concurrent Versions System), a freely available source code control tool.
-In June 2008, the Project switched to using https://subversion.apache.org/[SVN] (Subversion).
+For several years, the central source tree for FreeBSD was maintained by link:http://www.nongnu.org/cvs/[CVS] (Concurrent Versions System), a freely available source code control tool.
+In June 2008, the Project switched to using link:https://subversion.apache.org/[SVN] (Subversion).
The switch was deemed necessary, as the technical limitations imposed by CVS were becoming obvious due to the rapid expansion of the source tree and the amount of history already stored.
The Documentation Project and Ports Collection repositories also moved from CVS to SVN in May 2012 and July 2012, respectively.
-In December 2020, the Project https://www.freebsd.org/status/report-2020-10-2020-12.html#Git-Migration-Working-Group[migrated Source and Documentation repositories] to https://git-scm.com/[Git], with https://www.freebsd.org/status/report-2021-04-2021-06/#_git_migration_working_group[Ports following suit] in April 2021.
+In December 2020, the Project link:https://www.freebsd.org/status/report-2020-10-2020-12.html#Git-Migration-Working-Group[migrated Source and Documentation repositories] to link:https://git-scm.com/[Git], with link:https://www.freebsd.org/status/report-2021-04-2021-06/#_git_migration_working_group[Ports following suit] in April 2021.
Please refer to the crossref:cutting-edge[synching, Obtaining the Source] section for more information on obtaining the FreeBSD `src/` repository and crossref:ports[ports-using, Using the Ports Collection] for details on obtaining the FreeBSD Ports Collection.
The committers list[[development-committers]]::
The _committers_ are the people who have _push_ access to the Git repository, and are authorized to make modifications to the FreeBSD source (the term "committer" comes from `commit`, the source control command which is used to bring new changes into the repository).
-Anyone can submit a bug to the https://bugs.FreeBSD.org/submit/[Bug Database].
+Anyone can submit a bug to the link:https://bugs.FreeBSD.org/submit/[Bug Database].
Before submitting a bug report, the FreeBSD mailing lists, IRC channels, or forums can be used to help verify that an issue is actually a bug.
The FreeBSD core team[[development-core]]::
The _FreeBSD core team_ would be equivalent to the board of directors if the FreeBSD Project were a company.
The primary task of the core team is to make sure the project, as a whole, is in good shape and is heading in the right directions.
Inviting dedicated and responsible developers to join our group of committers is one of the functions of the core team, as is the recruitment of new core team members as others move on.
-The current core team was elected from a pool of committer candidates in June 2020.
+The current core team was elected from a pool of committer candidates in May 2022.
Elections are held every 2 years.
+
[NOTE]
@@ -243,17 +242,27 @@ Like most developers, most members of the core team are also volunteers when it
The "board of directors" analogy above is not very accurate, and it may be more suitable to say that these are the people who gave up their lives in favor of FreeBSD against their better judgement!
====
+The FreeBSD Foundation[[development-foundation]]::
+The link:https://freebsdfoundation.org[FreeBSD Foundation] is a 501(c)(3), US-based, non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide.
+The Foundation funds software development via project grants and provides staff to immediately respond to urgent problems and implement new features and functionality.
+The Foundation purchases hardware to improve and maintain FreeBSD infrastructure, and funds staffing to improve test coverage, continuous integration and automation.
+The Foundation advocates for FreeBSD by promoting FreeBSD at technical conferences and events around the world.
+The Foundation also provides workshops, educational material, and presentations to recruit more users and contributors to FreeBSD.
+The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity.
+
Outside contributors::
Last, but definitely not least, the largest group of developers are the users themselves who provide feedback and bug fixes to us on an almost constant basis.
-The primary way of keeping in touch with FreeBSD's more non-centralized development is to subscribe to the {freebsd-hackers} where such things are discussed.
+The primary way of keeping in touch with development of FreeBSD base system is to subscribe to the {freebsd-hackers} where such things are discussed.
+For porting third party applications, it would be the {freebsd-ports}.
+For documentation - {freebsd-doc}.
See crossref:eresources[eresources, Resources on the Internet] for more information about the various FreeBSD mailing lists.
+
-extref:{contributors}[The FreeBSD Contributors List] is a long and growing one, so why not join it by contributing something back to FreeBSD today?
-+
-Providing code is not the only way of contributing to the project; for a more complete list of things that need doing, please refer to the link:https://www.FreeBSD.org/[FreeBSD Project web site].
+extref:{contributors}[The FreeBSD Contributors List] is a long and growing one, so why not join it by extref:{contributing}[contributing something back to FreeBSD] today?
+Providing code is not the only way!
In summary, our development model is organized as a loose set of concentric circles.
-The centralized model is designed for the convenience of the _users_ of FreeBSD, who are provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent crossref:ports[ports,application programs] that the users can easily install and use - this model works very well in accomplishing that.
+The centralized model is designed for the convenience of the _users_ of FreeBSD, who are provided with an easy way of tracking one central code base, not to keep potential contributors out!
+Our desire is to present a stable operating system with a large set of coherent crossref:ports[ports,application programs] that the users can easily install and use - this model works very well in accomplishing that.
All we ask of those who would join us as FreeBSD developers is some of the same dedication its current people have to its continued success!
@@ -261,23 +270,25 @@ All we ask of those who would join us as FreeBSD developers is some of the same
=== Third Party Programs
In addition to the base distributions, FreeBSD offers a ported software collection with thousands of commonly sought-after programs.
-At the time of this writing, there were over {numports} ports! The list of ports ranges from http servers, to games, languages, editors, and almost everything in between.
-The entire Ports Collection requires approximately {ports-size}.
+The list of ports ranges from HTTP servers, to games, languages, editors, and almost everything in between.
+There are about {numports} ports; the entire Ports Collection requires approximately {ports-size}.
To compile a port, you simply change to the directory of the program you wish to install, type `make install`, and let the system do the rest.
The full original distribution for each port you build is retrieved dynamically so you need only enough disk space to build the ports you want.
+
Almost every port is also provided as a pre-compiled "package", which can be installed with a simple command (`pkg install`) by those who do not wish to compile their own ports from source.
More information on packages and ports can be found in crossref:ports[ports,Installing Applications: Packages and Ports].
=== Additional Documentation
All supported FreeBSD versions provide an option in the installer to install additional documentation under [.filename]#/usr/local/share/doc/freebsd# during the initial system setup.
-Documentation may also be installed at any later time using packages:
+Documentation may also be installed later using packages:
[source,shell]
....
# pkg install en-freebsd-doc
....
For localized versions replace the "en" with language prefix of choice.
+Be aware that some of the localised versions might be out of date and might contain information that is no longer correct or relevant.
You may view the locally installed manuals with a web browser using the following URLs:
The FreeBSD Handbook::
@@ -286,4 +297,4 @@ The FreeBSD Handbook::
The FreeBSD FAQ::
[.filename]#link:file://localhost/usr/local/share/doc/freebsd/en/books/faq/book.html[/usr/local/share/doc/freebsd/en/books/faq/book.html]#
-You can always find the up to date copy at https://docs.FreeBSD.org/[https://docs.FreeBSD.org/].
+You can always find up to date documentation at link:https://docs.FreeBSD.org/[https://docs.FreeBSD.org/].
diff --git a/documentation/content/en/books/handbook/jails/_index.adoc b/documentation/content/en/books/handbook/jails/_index.adoc
index 4bdb15bf53..36c177926a 100644
--- a/documentation/content/en/books/handbook/jails/_index.adoc
+++ b/documentation/content/en/books/handbook/jails/_index.adoc
@@ -764,7 +764,7 @@ It can be chosen by specifying a full URL for a particular download mirror in [.
ezjail_ftphost=http://ftp.FreeBSD.org
....
-See crossref:mirrors[mirrors-ftp,“FTP Sites”] for a list of sites.
+See the crossref:mirrors[mirrors,mirrors] section for a list of sites.
====
[[jails-ezjail-create]]
diff --git a/documentation/content/en/books/handbook/linuxemu/_index.adoc b/documentation/content/en/books/handbook/linuxemu/_index.adoc
index ff7b75b739..40f5f3a58f 100644
--- a/documentation/content/en/books/handbook/linuxemu/_index.adoc
+++ b/documentation/content/en/books/handbook/linuxemu/_index.adoc
@@ -89,7 +89,7 @@ This is enough for statically linked Linux binaries to work.
They can be started in the same way native FreeBSD binaries can; they behave almost exactly like native processes and can be traced and debugged the usual way.
Linux binaries linked dynamically (which is the vast majority) also require Linux shared libraries to be installed - they can run on top of the FreeBSD kernel, but they cannot use FreeBSD libraries; this is similar to how 32-bit binaries cannot use native 64-bit libraries.
-There are several ways of providing those libraries: one can copy them over from an existing Linux installation using the same architecture, install them from FreeBSD packages, or install using man:deboostrap[8] (from package:sysutils/debootstrap[]), and others.
+There are several ways of providing those libraries: one can copy them over from an existing Linux installation using the same architecture, install them from FreeBSD packages, or install using man:debootstrap[8] (from package:sysutils/debootstrap[]), and others.
[[linuxemu-packages]]
== CentOS Base System from FreeBSD Packages
@@ -107,7 +107,7 @@ The easiest way to install Linux libraries is to install package:emulators/linux
....
FreeBSD provides packages for some Linux binary applications.
-For example, to install Sublime Text 4, along all the Linux libraries it depends on, run this command:
+For example, to install Sublime Text 4, along with all the Linux libraries it depends on, run this command:
[source,shell]
....
# pkg install linux-sublime-text4
@@ -120,7 +120,7 @@ An alternative way of providing Linux shared libraries is by using package:sysut
This has the advantage of providing a full Debian or Ubuntu distribution.
To use it, follow the instructions at FreeBSD Wiki: https://wiki.freebsd.org/LinuxJails[FreeBSD Wiki - Linux Jails].
-After deboostrapping, chroot(8) into the newly created directory and install software in a way typical for the Linux distribution inside, for example:
+After debootstrapping, man:chroot[8] into the newly created directory and install software in a way typical for the Linux distribution inside, for example:
[source,shell]
....
@@ -137,7 +137,7 @@ If the bootstrapped instance is intended to provide Linux shared libraries witho
compat.linux.emul_path="/compat/ubuntu"
....
-This sysctl controls kernel's path translation mechanism; see the man:linux[4] man page for details.
+This sysctl controls the kernel's path translation mechanism; see man:linux[4] for details.
Please note that changing it might cause trouble for Linux applications installed from FreeBSD packages; one reason is that many of those applications are still 32-bit, while Ubuntu seems to be deprecating 32-bit library support.
[[linuxemu-advanced]]
@@ -288,7 +288,7 @@ This specifies that [.filename]#/etc/hosts# is searched first and DNS is searche
When [.filename]#/compat/linux/etc/host.conf# does not exist, Linux applications use [.filename]#/etc/host.conf# and complain about the incompatible FreeBSD syntax.
Remove `bind` if a name server is not configured using [.filename]#/etc/resolv.conf#.
-[[linuxemu-advanced]]
+[[linuxemu-misc]]
=== Miscellaneous
This section describes how Linux binary compatibility works and is based on an email written to {freebsd-chat} by Terry Lambert mailto:tlambert@primenet.com[tlambert@primenet.com] (Message ID: `<199906020108.SAA07001@usr09.primenet.com>`).
diff --git a/documentation/content/en/books/handbook/mac/_index.adoc b/documentation/content/en/books/handbook/mac/_index.adoc
index b6630ab398..431f01a1f6 100644
--- a/documentation/content/en/books/handbook/mac/_index.adoc
+++ b/documentation/content/en/books/handbook/mac/_index.adoc
@@ -52,7 +52,7 @@ endif::[]
== Synopsis
FreeBSD supports security extensions based on the POSIX(R).1e draft.
-These security mechanisms include file system Access Control Lists (crossref:security[fs-acl,“Access Control Lists”]) and Mandatory Access Control (MAC).
+These security mechanisms include file system Access Control Lists (crossref:security[fs-acl,“Access Control Lists”]) and Mandatory Access Control (MAC).
MAC allows access control modules to be loaded in order to implement security policies.
Some modules provide protections for a narrow subset of the system, hardening a particular service.
Others provide comprehensive labeled security across all subjects and objects.
@@ -133,7 +133,7 @@ Basic control over objects will then be released to the group, but `root` may re
When appropriate, a multi label policy can be set on a UFS file system by passing `multilabel` to man:tunefs[8].
A multi label policy permits each subject or object to have its own independent MAC label.
-The decision to use a multi label or single label policy is only required for policies which implement the labeling feature, such as `biba`, `lomac`, and `mls`.
+The decision to use a multi label or single label policy is only required for policies which implement the labeling feature, such as `biba`, `lomac`, and `mls`.
Some policies, such as `seeotheruids`, `portacl` and `partition`, do not use labels at all.
Using a multi label policy on a partition and establishing a multi label security model can increase administrative overhead as everything in that file system has a label.
@@ -208,7 +208,7 @@ Refer to the manual page of the module to determine the traits of the generic la
=== Numeric Labels
The Biba and MLS policy modules support a numeric label which may be set to indicate the precise level of hierarchical control.
-This numeric level is used to partition or sort information into different groups of classification, only permitting access to that group or a higher group level.
+This numeric level is used to partition or sort information into different groups of classification, only permitting access to that group or a higher group level.
For example:
[.programlisting]
@@ -553,7 +553,7 @@ Boot option: `mac_mls_load="YES"`
The man:mac_mls[4] policy controls access between subjects and objects in the system by enforcing a strict information flow policy.
In MLS environments, a "clearance" level is set in the label of each subject or object, along with compartments.
-Since these clearance levels can reach numbers greater than several thousand, it would be a daunting task to thoroughly configure every subject or object.
+Since these clearance levels can reach numbers greater than several thousand, it would be a daunting task to thoroughly configure every subject or object.
To ease this administrative overhead, three labels are included in this policy: `mls/low`, `mls/equal`, and `mls/high`, where:
* Anything labeled with `mls/low` will have a low clearance level and not be permitted to access information of a higher level. This label also prevents objects of a higher clearance level from writing or passing information to a lower level.
@@ -595,7 +595,7 @@ The default `block read up block write down` sets everything to a low state.
Everything is accessible and an administrator slowly augments the confidentiality of the information.
Beyond the three basic label options, an administrator may group users and groups as required to block the information flow between them.
-It might be easier to look at the information in clearance levels using descriptive words, such as classifications of `Confidential`, `Secret`, and `Top Secret`.
+It might be easier to look at the information in clearance levels using descriptive words, such as classifications of `Confidential`, `Secret`, and `Top Secret`.
Some administrators instead create different groups based on project levels.
Regardless of the classification method, a well thought out plan must exist before implementing a restrictive policy.
diff --git a/documentation/content/en/books/handbook/mail/_index.adoc b/documentation/content/en/books/handbook/mail/_index.adoc
index 7632825a6c..e433388bc6 100644
--- a/documentation/content/en/books/handbook/mail/_index.adoc
+++ b/documentation/content/en/books/handbook/mail/_index.adoc
@@ -117,7 +117,7 @@ To secure the transmission of information across these protocols, consider tunne
Domain Name System (DNS)::
The Domain Name System (DNS) and its daemon `named` play a large role in the delivery of email.
-In order to deliver mail from one site to another, the MTA will look up the remote site in DNS to determine which host will receive mail for the destination.
+In order to deliver mail from one site to another, the MTA will look up the remote site in DNS to determine which host will receive mail for the destination.
This process also occurs when mail is sent from a remote host to the MTA.
+
In addition to mapping hostnames to IP addresses, DNS is responsible for storing information specific to mail delivery, known as Mail eXchanger MX records.
@@ -137,7 +137,7 @@ Refer to crossref:network-servers[network-dns,"Domain Name System (DNS)"] for mo
[[sendmail]]
== Sendmail Configuration Files
-Sendmail is the default MTA installed with FreeBSD. It accepts mail from MUAs and delivers it to the appropriate mail host, as defined by its configuration.
+Sendmail is the default MTA installed with FreeBSD. It accepts mail from MUAs and delivers it to the appropriate mail host, as defined by its configuration.
Sendmail can also accept network connections and deliver mail to local mailboxes or to another program.
The configuration files for Sendmail are located in [.filename]#/etc/mail#.
@@ -212,7 +212,7 @@ Whenever this file is updated, run `newaliases` to update and initialize the ali
[.filename]#/etc/mail/sendmail.cf#::
This is the master configuration file for Sendmail.
-It controls the overall behavior of Sendmail, including everything from rewriting email addresses to printing rejection messages to remote mail servers.
+It controls the overall behavior of Sendmail, including everything from rewriting email addresses to printing rejection messages to remote mail servers.
Accordingly, this configuration file is quite complex.
Fortunately, this file rarely needs to be changed for standard mail servers.
+
@@ -315,7 +315,7 @@ More information on Sendmail's startup options is available in man:rc.sendmail[8
=== Replace the Default MTA
-When a new MTA is installed using the Ports Collection, its startup script is also installed and startup instructions are mentioned in its package message.
+When a new MTA is installed using the Ports Collection, its startup script is also installed and startup instructions are mentioned in its package message.
Before starting the new MTA, stop the running Sendmail processes.
This example stops all of these services, then starts the Postfix service:
@@ -567,7 +567,7 @@ Your ISP can provide this service.
[[mail-domain]]
=== Mail for a Domain
-When configuring a MTA for a network, any mail sent to hosts in its domain should be diverted to the MTA so that users can receive their mail on the master mail server.
+When configuring an MTA for a network, any mail sent to hosts in its domain should be diverted to the MTA so that users can receive their mail on the master mail server.
To make life easiest, a user account with the same _username_ should exist on both the MTA and the system with the MUA.
Use man:adduser[8] to create the user accounts.
diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc
index a634b6ff2a..d144111c60 100644
--- a/documentation/content/en/books/handbook/mirrors/_index.adoc
+++ b/documentation/content/en/books/handbook/mirrors/_index.adoc
@@ -11,7 +11,6 @@ path: "/books/handbook/"
---
[appendix]
-[[mirrors]]
= Obtaining FreeBSD
:doctype: book
:toc: macro
@@ -49,493 +48,235 @@ toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
-[[mirrors-http]]
-== HTTP Mirrors
-
-The official sources for FreeBSD are available via HTTP from a worldwide set of mirror sites.
-The site {central-http} is available via HTTP and anonymous FTP.
-It is made up of many machines operated by the project cluster administrators and behind GeoDNS to direct users to the closest available mirror.
-
-[[primary]]
-*{mirrors-primary}*
-
-In case of problems, please contact the hostmaster `<{mirrors-primary-email}>` for this domain.
-
-* {mirrors-primary-ftp4-http} / {mirrors-primary-ftp4-httpv6}
-* {mirrors-primary-ftp10-http} / {mirrors-primary-ftp10-httpv6}
-* {mirrors-primary-ftp14-http}
-
-[[armenia]]
-*{mirrors-armenia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-armenia-email}>` for this domain.
-
-* {mirrors-armenia-ftp-http}
-
-[[austria]]
-*{mirrors-austria}*
-
-In case of problems, please contact the hostmaster `<{mirrors-austria-email}>` for this domain.
-
-* {mirrors-austria-ftp-http} / {mirrors-austria-ftp-httpv6}
-
-[[brazil]]
-*{mirrors-brazil}*
-
-In case of problems, please contact the hostmaster `<{mirrors-brazil-email}>` for this domain.
-
-* {mirrors-brazil-ftp2-http}
-
-[[bulgaria]]
-*{mirrors-bulgaria}*
-
-In case of problems, please contact the hostmaster `<{mirrors-bulgaria-email}>` for this domain.
-
-* {mirrors-bulgaria-ftp-http} / {mirrors-bulgaria-ftp-httpv6}
-
-[[czech-republic]]
-*{mirrors-czech}*
-
-In case of problems, please contact the hostmaster `<{mirrors-czech-email}>` for this domain.
-
-* {mirrors-czech-ftp-http} / {mirrors-czech-ftp-httpv6}
-* {mirrors-czech-ftp2-http}
-
-[[denmark]]
-*{mirrors-denmark}*
-
-In case of problems, please contact the hostmaster `<{mirrors-denmark-email}>` for this domain.
-
-* {mirrors-denmark-ftp-http} / {mirrors-denmark-ftp-httpv6}
-
-[[france]]
-*{mirrors-france}*
-
-In case of problems, please contact the hostmaster `<{mirrors-france-email}>` for this domain.
-
-* {mirrors-france-ftp1-http}
-
-[[germany]]
-*{mirrors-germany}*
-
-In case of problems, please contact the hostmaster `<{mirrors-germany-email}>` for this domain.
-
-* http://www1.de.FreeBSD.org/freebsd/
-* http://ftp2.de.FreeBSD.org/pub/FreeBSD/
-* http://ftp4.de.FreeBSD.org/pub/FreeBSD/
-* http://ftp7.de.FreeBSD.org/pub/FreeBSD/
-
-[[korea]]
-*{mirrors-korea}*
-
-In case of problems, please contact the hostmaster `<{mirrors-korea-email}>` for this domain.
-
-* {mirrors-korea-ftp2-http}
-
-[[latvia]]
-*{mirrors-latvia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-latvia-email}>` for this domain.
-
-* {mirrors-latvia-ftp-http}
-
-[[lithuania]]
-*{mirrors-lithuania}*
-
-In case of problems, please contact the hostmaster `<{mirrors-lithuania-email}>` for this domain.
-
-* {mirrors-lithuania-ftp-http}
-
-[[netherlands]]
-*{mirrors-netherlands}*
-
-In case of problems, please contact the hostmaster `<{mirrors-netherlands-email}>` for this domain.
-
-* {mirrors-netherlands-ftp-http}
-
-[[new-zealand]]
-*{mirrors-new-zealand}*
-
-* {mirrors-new-zealand-ftp-http}
-
-[[russia]]
-*{mirrors-russia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-russia-email}>` for this domain.
-
-* {mirrors-russia-ftp-http}
-* {mirrors-russia-ftp2-http}
-* {mirrors-russia-ftp5-http}
-
-[[spain]]
-*{mirrors-spain}*
-
-In case of problems, please contact the hostmaster `<{mirrors-spain-email}>` for this domain.
-
-* {mirrors-spain-ftp-http}
-
-[[sweden]]
-*{mirrors-sweden}*
-
-In case of problems, please contact the hostmaster `<{mirrors-sweden-email}>` for this domain.
-
-* {mirrors-sweden-ftp4-http} / {mirrors-sweden-ftp4-httpv6}
-* {mirrors-sweden-ftp6-http}
-
-[[switzerland]]
-*{mirrors-switzerland}*
-
-In case of problems, please contact the hostmaster `<{mirrors-switzerland-email}>` for this domain.
-
-* {mirrors-switzerland-ftp-http}
-
-[[taiwan]]
-*{mirrors-taiwan}*
-
-In case of problems, please contact the hostmaster `<{mirrors-taiwan-email}>` for this domain.
-
-* {mirrors-taiwan-ftp2-http} / {mirrors-taiwan-ftp2-httpv6}
-* {mirrors-taiwan-ftp11-http}
-
-[[ukraine]]
-*{mirrors-ukraine}*
-
-* {mirrors-ukraine-ftp-http}
-* {mirrors-ukraine-ftp6-http}
-
-[[usa]]
-*{mirrors-us}*
-
-In case of problems, please contact the hostmaster `<{mirrors-us-email}>` for this domain.
-
-* {mirrors-us-ftp4-http} / {mirrors-us-ftp4-httpv6}
-* {mirrors-us-ftp13-http}
-* {mirrors-us-ftp14-http}
-
-[[mirrors-ftp]]
-== FTP Sites
-
-In addition to HTTP mirrors, FreeBSD is available via anonymous FTP from the following sites.
-When obtaining FreeBSD via anonymous FTP, please try to use a nearby site.
-The mirror sites listed as "Primary Mirror Sites" typically have the entire FreeBSD archive (all the currently available versions for each of the architectures) but faster download speeds are probably available from a site that is in your country or region.
-The regional sites carry the most recent versions for the most popular architecture(s) but might not carry the entire FreeBSD archive.
-All sites provide access via anonymous FTP but some sites also provide access via other methods.
-The access methods available for each site are provided in parentheses after the hostname.
-
-<<central, {central}>>, <<primary, {mirrors-primary}>>, <<armenia, {mirrors-armenia}>>, <<australia, {mirrors-australia}>>, <<austria, {mirrors-austria}>>, <<brazil, {mirrors-brazil}>>, <<bulgaria, {mirrors-bulgaria}>>, <<czech-republic, {mirrors-czech}>>, <<denmark, {mirrors-denmark}>>, <<estonia, {mirrors-estonia}>>, <<finland, {mirrors-finland}>>, <<france, {mirrors-france}>>, <<germany, {mirrors-germany}>>, <<greece, {mirrors-greece}>>, <<hong-kong, {mirrors-hongkong}>>, <<ireland, {mirrors-ireland}>>, <<japan, {mirrors-japan}>>, <<korea, {mirrors-korea}>>, <<latvia, {mirrors-latvia}>>, <<lithuania, {mirrors-lithuania}>>, <<netherlands, {mirrors-netherlands}>>, <<new-zealand, {mirrors-new-zealand}>>, <<norway, {mirrors-norway}>>, <<poland, {mirrors-poland}>>, <<russia, {mirrors-russia}>>, <<saudi-arabia, {mirrors-saudi-arabia}>>, <<slovenia, {mirrors-slovenia}>>, <<south-africa, {mirrors-south-africa}>>, <<spain, {mirrors-spain}>>, <<sweden, {mirrors-sweden}>>, <<switzerland, {mirrors-switzerland}>>, <<taiwan, {mirrors-taiwan}>>, <<ukraine, {mirrors-ukraine}>>, <<uk, {mirrors-uk}>>, <<usa, {mirrors-us}>>.
-
-[[central]]
-*{central}*
-
-{central-ftp} (ftp / ftpv6)
-
-[[primary]]
-*{mirrors-primary}*
-
-In case of problems, please contact the hostmaster `<{mirrors-primary-email}>` for this domain.
-
-* {mirrors-primary-ftp1} (ftp)
-* {mirrors-primary-ftp2} (ftp)
-* {mirrors-primary-ftp3} (ftp)
-* {mirrors-primary-ftp4} (ftp / ftpv6)
-* {mirrors-primary-ftp5} (ftp)
-* {mirrors-primary-ftp6} (ftp)
-* {mirrors-primary-ftp7} (ftp)
-* {mirrors-primary-ftp10} (ftp / ftpv6)
-* {mirrors-primary-ftp11} (ftp)
-* {mirrors-primary-ftp13} (ftp)
-* {mirrors-primary-ftp14} (ftp)
-
-[[armenia]]
-*{mirrors-armenia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-armenia-email}>` for this domain.
-
-* {mirrors-armenia-ftp} (ftp / rsync)
-
-[[australia]]
-*{mirrors-australia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-australia-email}>` for this domain.
-
-* {mirrors-australia-ftp} (ftp)
-* {mirrors-australia-ftp2} (ftp)
-* {mirrors-australia-ftp3} (ftp)
-
-[[austria]]
-*{mirrors-austria}*
-
-In case of problems, please contact the hostmaster `<{mirrors-austria-email}>` for this domain.
-
-* {mirrors-austria-ftp} (ftp / ftpv6)
-
-[[brazil]]
-*{mirrors-brazil}*
-
-In case of problems, please contact the hostmaster `<{mirrors-brazil-email}>` for this domain.
-
-* {mirrors-brazil-ftp2} (ftp)
-* {mirrors-brazil-ftp3} (ftp / rsync)
-* {mirrors-brazil-ftp4} (ftp)
-
-[[bulgaria]]
-*{mirrors-bulgaria}*
-
-In case of problems, please contact the hostmaster `<{mirrors-bulgaria-email}>` for this domain.
-
-* {mirrors-bulgaria-ftp} (ftp / {mirrors-bulgaria-ftpv6} / rsync / rsyncv6)
-
-[[czech-republic]]
-*{mirrors-czech}*
-
-In case of problems, please contact the hostmaster `<{mirrors-czech-email}>` for this domain.
-
-* {mirrors-czech-ftp} (ftp / {mirrors-czech-ftpv6} / rsync / rsyncv6)
-* {mirrors-czech-ftp2} (ftp)
-
-[[denmark]]
-*{mirrors-denmark}*
-
-In case of problems, please contact the hostmaster `<{mirrors-denmark-email}>` for this domain.
-
-* {mirrors-denmark-ftp} (ftp / ftpv6)
-
-[[estonia]]
-*{mirrors-estonia}*
-
-In case of problems, please contact the hostmaster `<{mirrors-estonia-email}>` for this domain.
-
-* {mirrors-estonia-ftp} (ftp)
-
-[[finland]]
-*{mirrors-finland}*
-
-In case of problems, please contact the hostmaster `<{mirrors-finland-email}>` for this domain.
-
-* {mirrors-finland-ftp} (ftp)
-
-[[france]]
-*{mirrors-france}*
-
-In case of problems, please contact the hostmaster `<{mirrors-france-email}>` for this domain.
-
-* {mirrors-france-ftp} (ftp)
-* {mirrors-france-ftp1} (ftp / rsync)
-* {mirrors-france-ftp3} (ftp)
-* {mirrors-france-ftp5} (ftp)
-* {mirrors-france-ftp6} (ftp / rsync)
-* {mirrors-france-ftp7} (ftp)
-* {mirrors-france-ftp8} (ftp)
-
-[[germany]]
-*{mirrors-germany}*
-
-In case of problems, please contact the hostmaster `<{mirrors-germany-email}>` for this domain.
-
-* ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ (ftp)
-* ftp://ftp1.de.FreeBSD.org/freebsd/ (ftp)
-* ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ (ftp / rsync)
-* ftp://ftp4.de.FreeBSD.org/FreeBSD/ (ftp)
-* ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ (ftp)
-* ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ (ftp)
-
-[[greece]]
-*{mirrors-greece}*
-
-In case of problems, please contact the hostmaster `<{mirrors-greece-email}>` for this domain.
-
-* {mirrors-greece-ftp} (ftp)
-* {mirrors-greece-ftp2} (ftp)
+[[mirrors]]
+== Mirrors
-[[hong-kong]]
-*{mirrors-hongkong}*
+The official mirrors of the FreeBSD project are made up of many machines operated by the project cluster administrators and behind GeoDNS to direct users to the closest available mirror.
+Current locations are Australia, Brazil, Japan (two sites), Malaysia, Netherlands, South Africa, Taiwan, United Kingdom, United States of America (California, New Jersey, and Washington).
-{mirrors-hongkong-ftp} (ftp)
+Official mirrors service:
-[[ireland]]
-*{mirrors-ireland}*
+[cols="1,1,3"]
+|===
+| Service Name | Protocols | More information
-In case of problems, please contact the hostmaster `<{mirrors-ireland-email}>` for this domain.
+| **download.FreeBSD.org**
+| link:https://download.FreeBSD.org/[https] link:ftp://download.FreeBSD.org/pub/FreeBSD/[ftp]
+| Same content as `ftp.FreeBSD.org`, `ftp` is a legacy name; `download.FreeBSD.org` is recommended.
-* {mirrors-ireland-ftp} (ftp / rsync)
+| **git.FreeBSD.org**
+| git over `https` and `ssh`
+| More details on link:https://docs.freebsd.org/en/books/handbook/mirrors/#git[using git] section.
-[[japan]]
-*{mirrors-japan}*
+| **pkg.FreeBSD.org**
+| man:pkg[8] over `http` and `https`
+| Official FreeBSD package repositories used by the man:pkg[8] program.
+|===
-In case of problems, please contact the hostmaster `<{mirrors-japan-email}>` for this domain.
+All official mirrors support IPv4 and IPv6.
-* {mirrors-japan-ftp} (ftp)
-* {mirrors-japan-ftp2} (ftp)
-* {mirrors-japan-ftp3} (ftp)
-* {mirrors-japan-ftp4} (ftp)
-* {mirrors-japan-ftp5} (ftp)
-* {mirrors-japan-ftp6} (ftp)
-* {mirrors-japan-ftp7} (ftp)
-* {mirrors-japan-ftp8} (ftp)
-* {mirrors-japan-ftp9} (ftp)
+The FreeBSD website (https://www.FreeBSD.org and https://docs.FreeBSD.org) are not hosted in the GeoDNS Infrastructure; there are ongoing studies of its implementation.
-[[korea]]
-*{mirrors-korea}*
+http://ftp-archive.FreeBSD.org is not in the GeoDNS Infrastructure, hosted in only one location (US).
-In case of problems, please contact the hostmaster `<{mirrors-korea-email}>` for this domain.
+The project is looking for new locations; those willing to sponsor, please reach out to the Cluster Administrators team for more information.
-* {mirrors-korea-ftp} (ftp / rsync)
-* {mirrors-korea-ftp2} (ftp)
+Mirror list maintained by the community and other companies:
-[[latvia]]
-*{mirrors-latvia}*
+[cols="1,1,3"]
+|===
+|Country | Hostname | Protocols
-In case of problems, please contact the hostmaster `<{mirrors-latvia-email}>` for this domain.
+| Australia icon:envelope[link=mailto:{mirrors-australia-email}, title="mirror contact"]
+| ftp.au.FreeBSD.org
+| link:http://ftp.au.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.au.FreeBSD.org/pub/FreeBSD[http_v6] link:rsync://ftp.au.FreeBSD.org[rsync] link:rsync://ftp.au.FreeBSD.org[rsync_v6]
-* {mirrors-latvia-ftp} (ftp)
+|
+| ftp3.au.FreeBSD.org
+| link:http://ftp3.au.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp3.au.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp3.au.FreeBSD.org[rsync]
-[[lithuania]]
-*{mirrors-lithuania}*
+| Austria icon:envelope[link=mailto:{mirrors-austria-email}, title="mirror contact"]
+| ftp.at.FreeBSD.org
+| link:http://ftp.at.FreeBSD.org/pub/FreeBSD/[http] link:http://ftp.at.FreeBSD.org/pub/FreeBSD/[http_v6] link:ftp://ftp.at.FreeBSD.org/pub/FreeBSD/[ftp] link:ftp://ftp.at.FreeBSD.org/pub/FreeBSD/[ftp_v6] link:rsync://ftp.at.FreeBSD.org/pub/FreeBSD/[rsync] link:rsync://ftp.at.FreeBSD.org/pub/FreeBSD/[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-lithuania-email}>` for this domain.
+| Brazil icon:envelope[link=mailto:{mirrors-brazil-email}, title="mirror contact"]
+| ftp2.br.FreeBSD.org
+| link:http://ftp2.br.FreeBSD.org/FreeBSD[http] link:rsync://ftp2.br.FreeBSD.org[rsync] link:rsync://ftp2.br.FreeBSD.org[rsync_v6]
-* {mirrors-lithuania-ftp} (ftp)
+|
+| ftp3.br.FreeBSD.org
+| link:http://ftp3.br.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp3.br.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp3.br.FreeBSD.org[rsync]
-[[netherlands]]
-*{mirrors-netherlands}*
+| Bulgaria icon:envelope[link=mailto:{mirrors-bulgaria-email}, title="mirror contact"]
+| ftp.bg.FreeBSD.org
+| link:ftp://ftp.bg.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.bg.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.bg.FreeBSD.org[rsync] link:rsync://ftp.bg.FreeBSD.org[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-netherlands-email}>` for this domain.
+| Czech Republic icon:envelope[link=mailto:{mirrors-czech-email}, title="mirror contact"]
+| ftp.cz.FreeBSD.org
+| link:http://ftp.cz.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.cz.FreeBSD.org/pub/FreeBSD[http_v6] link:rsync://ftp.cz.FreeBSD.org[rsync] link:rsync://ftp.cz.FreeBSD.org[rsync_v6]
-* {mirrors-netherlands-ftp} (ftp / rsync)
-* {mirrors-netherlands-ftp2} (ftp)
+| Denmark icon:envelope[link=mailto:{mirrors-denmark-email}, title="mirror contact"]
+| ftp.dk.FreeBSD.org
+| link:http://ftp.dk.FreeBSD.org/FreeBSD/[http] link:http://ftp.dk.FreeBSD.org/FreeBSD/[http_v6] link:ftp://ftp.dk.FreeBSD.org/FreeBSD/[ftp] link:ftp://ftp.dk.FreeBSD.org/FreeBSD/[ftp_v6] link:rsync://ftp.dk.FreeBSD.org/FreeBSD/[rsync] link:rsync://ftp.dk.FreeBSD.org/FreeBSD/[rsync_v6]
-[[new-zealand]]
-*{mirrors-new-zealand}*
+| Finland icon:envelope[link=mailto:{mirrors-finland-email}, title="mirror contact"]
+| ftp.fi.FreeBSD.org
+| link:ftp://ftp.fi.FreeBSD.org/pub/FreeBSD[ftp]
-* {mirrors-new-zealand-ftp} (ftp)
+| France icon:envelope[link=mailto:{mirrors-france-email}, title="mirror contact"]
+| ftp.fr.FreeBSD.org
+| link:http://ftp.fr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.fr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.fr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.fr.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.fr.FreeBSD.org[rsync] link:rsync://ftp.fr.FreeBSD.org[rsync_v6]
-[[norway]]
-*{mirrors-norway}*
+|
+| ftp3.fr.FreeBSD.org
+| link:ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD[ftp]
-In case of problems, please contact the hostmaster `<{mirrors-norway-email}>` for this domain.
+|
+| ftp6.fr.FreeBSD.org
+| link:http://ftp6.fr.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp6.fr.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp6.fr.FreeBSD.org[rsync]
-* {mirrors-norway-ftp} (ftp / rsync)
+| Germany icon:envelope[link=mailto:{mirrors-germany-email}, title="mirror contact"]
+| ftp.de.FreeBSD.org
+| link:ftp://ftp.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.de.FreeBSD.org[rsync] link:rsync://ftp.de.FreeBSD.org[rsync_v6]
-[[poland]]
-*{mirrors-poland}*
+|
+| ftp1.de.FreeBSD.org
+| link:http://ftp1.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp1.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp1.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp1.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp1.de.FreeBSD.org[rsync] link:rsync://ftp1.de.FreeBSD.org[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-poland-email}>` for this domain.
+|
+| ftp2.de.FreeBSD.org
+| link:http://ftp2.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp2.de.FreeBSD.org[rsync] link:rsync://ftp2.de.FreeBSD.org[rsync_v6]
-* {mirrors-poland-ftp} (ftp)
-* ftp2.pl.FreeBSD.org
+|
+| ftp5.de.FreeBSD.org
+| link:ftp://ftp5.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp5.de.FreeBSD.org/pub/FreeBSD[ftp_v6]
-[[russia]]
-*{mirrors-russia}*
+|
+| ftp7.de.FreeBSD.org
+| link:http://ftp7.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp7.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp7.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp7.de.FreeBSD.org/pub/FreeBSD[ftp_v6]
-In case of problems, please contact the hostmaster `<{mirrors-russia-email}>` for this domain.
+| Greece icon:envelope[link=mailto:{mirrors-greece-email}, title="mirror contact"]
+| ftp.gr.FreeBSD.org
+| link:http://ftp.gr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.gr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.gr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.gr.FreeBSD.org/pub/FreeBSD[ftp_v6]
-* {mirrors-russia-ftp} (ftp / rsync)
-* {mirrors-russia-ftp2} (ftp / rsync)
-* {mirrors-russia-ftp5} (ftp / rsync)
-* {mirrors-russia-ftp6} (ftp)
+|
+| ftp2.gr.FreeBSD.org
+| link:http://ftp2.gr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.gr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp2.gr.FreeBSD.org[rsync]
-[[saudi-arabia]]
-*{mirrors-saudi-arabia}*
+| Japan icon:envelope[link=mailto:{mirrors-japan-email}, title="mirror contact"]
+| ftp.jp.FreeBSD.org
+| link:http://ftp.jp.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.jp.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.jp.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.jp.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.jp.FreeBSD.org[rsync] link:rsync://ftp.jp.FreeBSD.org[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-saudi-arabia-email}>` for this domain.
+|
+| ftp2.jp.FreeBSD.org
+| link:ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.jp.FreeBSD.org[rsync] link:rsync://ftp2.jp.FreeBSD.org[rsync_v6]
-* {mirrors-saudi-arabia-ftp} (ftp)
+|
+| ftp3.jp.FreeBSD.org
+| link:http://ftp3.jp.FreeBSD.org/pub/FreeBSD[http] link:rsync://ftp3.jp.FreeBSD.org[rsync]
-[[slovenia]]
-*{mirrors-slovenia}*
+|
+| ftp4.jp.FreeBSD.org
+| link:ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD[ftp]
-In case of problems, please contact the hostmaster `<{mirrors-slovenia-email}>` for this domain.
+|
+| ftp6.jp.FreeBSD.org
+| link:http://ftp6.jp.FreeBSD.org/pub/FreeBSD[http] link:http://ftp6.jp.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp6.jp.FreeBSD.org[rsync] link:rsync://ftp6.jp.FreeBSD.org[rsync_v6]
-* {mirrors-slovenia-ftp} (ftp)
+| Korea icon:envelope[link=mailto:{mirrors-korea-email}, title="mirror contact"]
+| ftp.kr.FreeBSD.org
+| link:http://ftp.kr.FreeBSD.org/pub/FreeBSD[http] link:https://ftp.kr.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp.kr.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp.kr.FreeBSD.org[rsync]
-[[south-africa]]
-*{mirrors-south-africa}*
+|
+| ftp2.kr.FreeBSD.org
+| link:rsync://ftp2.kr.FreeBSD.org[rsync]
-In case of problems, please contact the hostmaster `<{mirrors-south-africa-email}>` for this domain.
+| Latvia icon:envelope[link=mailto:{mirrors-latvia-email}, title="mirror contact"]
+| ftp.lv.FreeBSD.org
+| link:http://ftp.lv.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.lv.FreeBSD.org/pub/FreeBSD[ftp]
-* {mirrors-south-africa-ftp} (ftp)
-* {mirrors-south-africa-ftp2} (ftp)
-* {mirrors-south-africa-ftp4} (ftp)
+| Netherlands icon:envelope[link=mailto:{mirrors-netherlands-email}, title="mirror contact"]
+| ftp.nl.FreeBSD.org
+| link:http://ftp.nl.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.nl.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.nl.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.nl.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.nl.FreeBSD.org[rsync] link:rsync://ftp.nl.FreeBSD.org[rsync_v6]
-[[spain]]
-*{mirrors-spain}*
+|
+| ftp2.nl.FreeBSD.org
+| link:http://ftp2.nl.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp2.nl.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.nl.FreeBSD.org[rsync]
-In case of problems, please contact the hostmaster `<{mirrors-spain-email}>` for this domain.
+| New Zealand icon:envelope[link=mailto:{mirrors-new-zealand-email}, title="mirror contact"]
+| ftp.nz.FreeBSD.org
+| link:http://ftp.nz.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.nz.FreeBSD.org/pub/FreeBSD[ftp]
-* {mirrors-spain-ftp} (ftp)
-* {mirrors-spain-ftp3} (ftp)
+| Norway icon:envelope[link=mailto:{mirrors-norway-email}, title="mirror contact"]
+| ftp.no.FreeBSD.org
+| link:ftp://ftp.no.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.no.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.no.FreeBSD.org[rsync] link:rsync://ftp.no.FreeBSD.org[rsync_v6]
-[[sweden]]
-*{mirrors-sweden}*
+| Poland icon:envelope[link=mailto:{mirrors-poland-email}, title="mirror contact"]
+| ftp.pl.FreeBSD.org
+| link:http://ftp.pl.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.pl.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.pl.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp.pl.FreeBSD.org[rsync] link:rsync://ftp.pl.FreeBSD.org[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-sweden-email}>` for this domain.
+| Russia icon:envelope[link=mailto:{mirrors-russia-email}, title="mirror contact"]
+| ftp.ru.FreeBSD.org
+| link:http://ftp.ru.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.ru.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.ru.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.ru.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.ru.FreeBSD.org[rsync] link:rsync://ftp.ru.FreeBSD.org[rsync_v6]
-* {mirrors-sweden-ftp} (ftp)
-* {mirrors-sweden-ftp2} (ftp)
-* {mirrors-sweden-ftp3} (ftp)
-* {mirrors-sweden-ftp4} (ftp / {mirrors-sweden-ftp4v6})
-* {mirrors-sweden-ftp6} (ftp)
+|
+| ftp2.ru.FreeBSD.org
+| link:https://ftp2.ru.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.ru.FreeBSD.org[rsync]
-[[switzerland]]
-*{mirrors-switzerland}*
+| Slovenia icon:envelope[link=mailto:{mirrors-slovenia-email}, title="mirror contact"]
+| ftp.si.FreeBSD.org
+| link:http://ftp.si.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.si.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.si.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.si.FreeBSD.org/pub/FreeBSD[ftp_v6]
-In case of problems, please contact the hostmaster `<{mirrors-switzerland-email}>` for this domain.
+| South Africa icon:envelope[link=mailto:{mirrors-south-africa-email}, title="mirror contact"]
+| ftp.za.FreeBSD.org
+| link:https://ftp.za.FreeBSD.org/pub/FreeBSD[https] link:https://ftp.za.FreeBSD.org/pub/FreeBSD[https_v6] link:rsync://ftp.za.FreeBSD.org[rsync] link:rsync://ftp.za.FreeBSD.org[rsync_v6]
-* {mirrors-switzerland-ftp} (ftp)
+|
+| ftp2.za.FreeBSD.org
+| link:http://ftp2.za.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.za.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.za.FreeBSD.org/pub/FreeBSD[ftp_v6]
-[[taiwan]]
-*{mirrors-taiwan}*
+|
+| ftp4.za.FreeBSD.org
+| link:http://ftp4.za.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp4.za.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp4.za.FreeBSD.org[rsync]
-In case of problems, please contact the hostmaster `<{mirrors-taiwan-email}>` for this domain.
+| Sweden icon:envelope[link=mailto:{mirrors-sweden-email}, title="mirror contact"]
+| ftp.se.FreeBSD.org
+| link:http://ftp.se.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.se.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.se.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.se.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.se.FreeBSD.org[rsync] link:rsync://ftp.se.FreeBSD.org[rsync_v6]
-* {mirrors-taiwan-ftp} (ftp / {mirrors-taiwan-ftpv6} / rsync / rsyncv6)
-* {mirrors-taiwan-ftp2} (ftp / {mirrors-taiwan-ftp2v6} / rsync / rsyncv6)
-* {mirrors-taiwan-ftp4} (ftp)
-* {mirrors-taiwan-ftp5} (ftp)
-* {mirrors-taiwan-ftp6} (ftp / {mirrors-taiwan-ftp6v6} / rsync)
-* {mirrors-taiwan-ftp7} (ftp)
-* {mirrors-taiwan-ftp8} (ftp)
-* {mirrors-taiwan-ftp11} (ftp)
-* {mirrors-taiwan-ftp12} (ftp)
-* {mirrors-taiwan-ftp13} (ftp)
-* {mirrors-taiwan-ftp14} (ftp)
-* {mirrors-taiwan-ftp15} (ftp)
+| Taiwan icon:envelope[link=mailto:{mirrors-taiwan-email}, title="mirror contact"]
+| ftp4.tw.FreeBSD.org
+| link:https://ftp4.tw.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp4.tw.FreeBSD.org[rsync]
-[[ukraine]]
-*{mirrors-ukraine}*
+|
+| ftp5.tw.FreeBSD.org
+| link:http://ftp5.tw.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp5.tw.FreeBSD.org/pub/FreeBSD[ftp]
-* {mirrors-ukraine-ftp} (ftp)
-* {mirrors-ukraine-ftp6} (ftp)
-* {mirrors-ukraine-ftp7} (ftp)
+| Ukraine icon:envelope[link=mailto:{mirrors-ukraine-email}, title="mirror contact"]
+| ftp.ua.FreeBSD.org
+| link:http://ftp.ua.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.ua.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.ua.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.ua.FreeBSD.org[rsync] link:rsync://ftp.ua.FreeBSD.org[rsync_v6]
-[[uk]]
-*{mirrors-uk}*
+| United Kingdom icon:envelope[link=mailto:{mirrors-uk-email}, title="mirror contact"]
+| ftp.uk.FreeBSD.org
+| link:http://ftp.uk.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.uk.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.uk.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.uk.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.uk.FreeBSD.org[rsync] link:rsync://ftp.uk.FreeBSD.org[rsync_v6]
-In case of problems, please contact the hostmaster `<{mirrors-uk-email}>` for this domain.
+|
+| ftp2.uk.FreeBSD.org
+| link:http://ftp2.uk.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.uk.FreeBSD.org/pub/FreeBSD[http_v6] link:https://ftp2.uk.FreeBSD.org/pub/FreeBSD[https] link:https://ftp2.uk.FreeBSD.org/pub/FreeBSD[https_v6] link:ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD[ftp_v6]
-* {mirrors-uk-ftp} (ftp)
-* {mirrors-uk-ftp2} (ftp)
-* {mirrors-uk-ftp3} (ftp)
-* {mirrors-uk-ftp4} (ftp)
-* {mirrors-uk-ftp5} (ftp)
+| United States of America icon:envelope[link=mailto:{mirrors-us-email}, title="mirror contact"]
+| ftp11.FreeBSD.org
+| link:http://ftp11.FreeBSD.org/pub/FreeBSD[http] link:http://ftp11.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp11.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp11.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp11.FreeBSD.org[rsync] link:rsync://ftp11.FreeBSD.org[rsync_v6]
-[[usa]]
-*{mirrors-us}*
+|
+| ftp14.FreeBSD.org
+| link:ftp://ftp14.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp14.FreeBSD.org[rsync] (Former official tier 1)
-In case of problems, please contact the hostmaster `<{mirrors-us-email}>` for this domain.
+|
+| ftp5.FreeBSD.org
+| link:http://ftp5.FreeBSD.org/pub/FreeBSD[http] link:http://ftp5.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp5.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp5.FreeBSD.org/pub/FreeBSD[ftp_v6]
+|===
-* {mirrors-us-ftp} (ftp)
-* {mirrors-us-ftp2} (ftp)
-* {mirrors-us-ftp3} (ftp)
-* {mirrors-us-ftp4} (ftp / ftpv6)
-* {mirrors-us-ftp5} (ftp)
-* {mirrors-us-ftp6} (ftp)
-* {mirrors-us-ftp8} (ftp)
-* {mirrors-us-ftp10} (ftp)
-* {mirrors-us-ftp11} (ftp)
-* {mirrors-us-ftp13} (ftp / rsync)
-* {mirrors-us-ftp14} (ftp)
-* {mirrors-us-ftp15} (ftp)
+The current list of protocols supported by the community mirrors was last updated on 2022-01-31, and it's not guaranteed.
[[git]]
== Using Git
@@ -552,127 +293,64 @@ Git is generally a developer tool.
Users may prefer to use `freebsd-update` (crossref:cutting-edge[updating-upgrading-freebsdupdate,“FreeBSD Update”]) to update the FreeBSD base system, and `portsnap` (crossref:ports[ports-using,“Using the Ports Collection”]) to update the FreeBSD Ports Collection.
====
-This section demonstrates how to install Git on a FreeBSD system and use it to create a local copy of a FreeBSD repository.
-Additional information on the use of Git is included.
-
-[[git-ssl-certificates]]
-=== Root SSL Certificates
-
-FreeBSD systems older than 12._x_ do not have proper root certificates.
-Installing package:security/ca_root_nss[] on these systems allows Git to verify the identity of HTTPS repository servers.
-The root SSL certificates can be installed from a port:
-
-[source,shell]
-....
-# cd /usr/ports/security/ca_root_nss
-# make install clean
-....
-
-or as a package:
-
-[source,shell]
-....
-# pkg install ca_root_nss
-....
+This section demonstrates how to install Git on a FreeBSD system and use it to create a local copy of a FreeBSD source code repository.
[[git-install]]
=== Installation
-Git can be installed as a package:
+Git can be installed from the Ports Collection, or as a package:
[source,shell]
....
# pkg install git
....
-Git can also be installed from the Ports Collection:
-
-[source,shell]
-....
-# cd /usr/ports/devel/git
-# make install clean
-....
-
[[git-usage]]
=== Running Git
-To fetch a clean copy of the sources into a local directory, use `git`.
+To fetch a clean copy of the sources into a local directory, use `git clone`.
This directory of files is called the _working tree_.
-[WARNING]
-====
-
-Move or delete an existing destination directory before using `git clone` for the first time.
-Cloning over an existing non-git directory will fail.
-====
-
-Git uses URLs to designate a repository, taking the form of _protocol://hostname/path_.
-The first component of the path is the FreeBSD repository to access.
+Git uses URLs to designate a repository.
There are three different repositories, `src` for the FreeBSD system source code, `doc` for documentation, and `ports` for the FreeBSD Ports Collection.
-For example, the URL `https://git.FreeBSD.org/src.git` specifies the main branch of the src repository, using the `https` protocol.
+All three are reachable over two different protocols: HTTPS and SSH.
+For example, the URL `https://git.FreeBSD.org/src.git` specifies the main branch of the `src` repository, using the `https` protocol.
[[git-url-table]]
.FreeBSD Git Repository URL Table
[options="header,footer"]
|=======================================================
|Item | Git URL
-| Web-based repository browser src | `https://cgit.freebsd.org/src`
-| Read-only src repo via HTTPS | `https://git.freebsd.org/src.git`
-| Read-only src repo via anon-ssh | `ssh://anongit@git.freebsd.org/src.git`
-| Read/write src repo for committers | `ssh://git@gitrepo.freebsd.org/src.git` (*)
-| Web-based repository browser doc | `https://cgit.freebsd.org/doc`
-| Read-only doc repo via HTTPS | `https://git.freebsd.org/doc.git`
-| Read-only doc repo via anon-ssh | `ssh://anongit@git.freebsd.org/doc.git`
-| Read/write doc repo for committers | `ssh://git@gitrepo.freebsd.org/doc.git` (*)
-| Web-based repository browser ports | `https://cgit.freebsd.org/ports`
-| Read-only ports repo via HTTPS | `https://git.freebsd.org/ports.git`
-| Read-only ports repo via anon-ssh | `ssh://anongit@git.freebsd.org/ports.git`
-| Read/write ports repo for committers | `ssh://git@gitrepo.freebsd.org/ports.git` (*)
+| Read-only src repo via HTTPS | `https://git.FreeBSD.org/src.git`
+| Read-only src repo via anon-ssh | `ssh://anongit@git.FreeBSD.org/src.git`
+| Read-only doc repo via HTTPS | `https://git.FreeBSD.org/doc.git`
+| Read-only doc repo via anon-ssh | `ssh://anongit@git.FreeBSD.org/doc.git`
+| Read-only ports repo via HTTPS | `https://git.FreeBSD.org/ports.git`
+| Read-only ports repo via anon-ssh | `ssh://anongit@git.FreeBSD.org/ports.git`
|=======================================================
- - (*) `git` is a special user on the repository server which will map your registered ssh key in FreeBSD.org to your identity, no need to change it.
-[WARNING]
-====
-Sometime after the switch to git is complete, `gitrepo.freebsd.org` will change to simply `repo.freebsd.org`.
-====
+External mirrors maintained by project members are also available; please refer to the <<external-mirrors>> section.
-To get started, clone a copy of the FreeBSD repository:
-
-[source,shell]
-....
-# git clone -o freebsd [ -b branch ] https://git.FreeBSD.org/repo.git wcdir
-....
-
-where:
-
-* _repo_ is one of the Project repositories: `src`, `ports`, or `doc`.
-* _branch_ depends on the repository used.
-`ports` and `doc` are mostly updated in the `main` branch, while `src` maintains the latest version of -CURRENT under `main` and the respective latest versions of the -STABLE branches under `stable/12` (12._x_) and `stable/13` (13._x_).
-* _wcdir_ is the target directory where the contents of the specified branch should be placed.
-This is usually [.filename]#/usr/ports# for `ports`, [.filename]#/usr/src# for `src`, and [.filename]#/usr/doc# for `doc`.
-* _freebsd_ is the name of the origin to use.
-By convention in the FreeBSD documentation, the origin is assumed to be `freebsd`.
-
-This example checks out the `main` branch of the system sources from the FreeBSD repository using the HTTPS protocol, placing the local working copy in [.filename]#/usr/src#.
-If [.filename]#/usr/src# is already present but was not created by `git`, remember to rename or delete it before the checkout.
-Git will refuse to do anything otherwise.
+To clone a copy of the FreeBSD system source code repository:
[source,shell]
....
# git clone -o freebsd https://git.FreeBSD.org/src.git /usr/src
....
+The `-o freebsd` option specifies the origin; by convention in the FreeBSD documentation, the origin is assumed to be `freebsd`.
Because the initial checkout must download the full branch of the remote repository, it can take a while.
Please be patient.
-After the initial checkout, the local working copy can be updated by running:
-
+Initially, the working tree contains source code for the `main` branch, which corresponds to CURRENT.
+To switch to 13-STABLE instead:
[source,shell]
....
-# cd wcdir
-# git pull --rebase
+# cd /usr/src
+# git checkout stable/13
....
+The working tree can be updated with `git pull`.
To update [.filename]#/usr/src# created in the example above, use:
[source,shell]
@@ -683,85 +361,54 @@ To update [.filename]#/usr/src# created in the example above, use:
The update is much quicker than a checkout, only transferring files that have changed.
-There are also external mirrors maintained by project members available, please refer to the <<external-mirrors>> section.
-
-=== SSH related information
-
-* `ssh://${user}@${url}/${repo}.git` can be written as `${user}@${url}:${repo}.git`, i.e., following two URLs are both valid for passing to `git`:
---
-** `ssh://anongit@git.freebsd.org/${repo}.git`
-** `anongit@git.freebsd.org:${repo}.git`
-
-As well as the read-write repo:
-
-** `ssh://git@(git)repo.freebsd.org/${repo}.git`
-** `git@(git)repo.freebsd.org:${repo}.git`
---
-
-* gitrepo.FreeBSD.org host key fingerprints:
-** ECDSA key fingerprint is `SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA`
-** ED25519 key fingerprint is `SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo`
-** RSA key fingerprint is `SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI`
-
-* git.FreeBSD.org host key fingerprints:
-** ECDSA key fingerprint is `SHA256:/UlirUAsGiitupxmtsn7f9b7zCWd0vCs4Yo/tpVWP9w`
-** ED25519 key fingerprint is `SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE`
-** RSA key fingerprint is `SHA256:jBe6FQGoH4HjvrIVM23dcnLZk9kmpdezR/CvQzm7rJM`
-
-These are also published as SSHFP records in DNS.
-
=== Web-based repository browser
-The FreeBSD project currently uses cgit as the web-based repository browser: https://cgit.freebsd.org/.
-The URLs of individual repositories are listed in <<git-url-table>>.
-
-=== For Users
-
-Using `git clone` and `git pull` from the official distributed mirrors is recommended.
-The GeoDNS should direct you to the nearest mirror to you.
+The FreeBSD project uses cgit as the web-based repository browser: link:https://cgit.FreeBSD.org/[https://cgit.FreeBSD.org/].
=== For Developers
-Please see the extref:{committers-guide}[Committer's Guide, git-mini-primer].
+For information about write access to repositories see the extref:{committers-guide}[Committer's Guide, git-mini-primer].
[[external-mirrors]]
=== External mirrors
Those mirrors are not hosted in FreeBSD.org but still maintained by the project members.
Users and developers are welcome to pull or browse repositories on those mirrors.
-The project workflow with those mirrors are still under discussion.
+Pull requests for the `doc` GitHub repository are being accepted; otherwise, the project workflow with those mirrors is still under discussion.
-==== Codeberg
+Codeberg::
- doc: https://codeberg.org/FreeBSD/freebsd-doc
- ports: https://codeberg.org/FreeBSD/freebsd-ports
- src: https://codeberg.org/FreeBSD/freebsd-src
-==== GitHub
+GitHub::
- doc: https://github.com/freebsd/freebsd-doc
- ports: https://github.com/freebsd/freebsd-ports
- src: https://github.com/freebsd/freebsd-src
-==== GitLab
+GitLab::
- doc: https://gitlab.com/FreeBSD/freebsd-doc
- ports: https://gitlab.com/FreeBSD/freebsd-ports
- src: https://gitlab.com/FreeBSD/freebsd-src
=== Mailing lists
-General usage and questions about git in the FreeBSD project: https://lists.freebsd.org/subscription/freebsd-git[freebsd-git]
+The main mailing list for general usage and questions about git in the FreeBSD project is https://lists.freebsd.org/subscription/freebsd-git[freebsd-git].
+For more details, including commit messages lists, see the crossref:handbook/eresources[eresources-mail, Mailing Lists] chapter.
-Commit messages will be sent to the following mailing lists:
+=== SSH host keys
+
+* gitrepo.FreeBSD.org host key fingerprints:
+** ECDSA key fingerprint is `SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA`
+** ED25519 key fingerprint is `SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo`
+** RSA key fingerprint is `SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI`
-- https://lists.freebsd.org/subscription/dev-commits-doc-all[dev-commits-doc-all]: All changes to the doc repository
-- https://lists.freebsd.org/subscription/dev-commits-ports-all[dev-commits-ports-all]: All changes to the ports repository
-- https://lists.freebsd.org/subscription/dev-commits-ports-main[dev-commits-ports-main]: All changes to the "main" branch of the ports repository
-- https://lists.freebsd.org/subscription/dev-commits-ports-branches[dev-commits-ports-branches]: All changes to the quarterly branches of the ports repository
-- https://lists.freebsd.org/subscription/dev-commits-src-all[dev-commits-src-all]: All changes to the src repository
-- https://lists.freebsd.org/subscription/dev-commits-src-main[dev-commits-src-main]: All changes to the "main" branch of the src repository (the FreeBSD-CURRENT branch)
-- https://lists.freebsd.org/subscription/dev-commits-src-branches[dev-commits-src-branches]: All changes to all stable branches of the src repository
+* git.FreeBSD.org host key fingerprints:
+** ECDSA key fingerprint is `SHA256:/UlirUAsGiitupxmtsn7f9b7zCWd0vCs4Yo/tpVWP9w`
+** ED25519 key fingerprint is `SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE`
+** RSA key fingerprint is `SHA256:jBe6FQGoH4HjvrIVM23dcnLZk9kmpdezR/CvQzm7rJM`
-For more information, please refer to the "Commit message lists" section of C.2.
-"Mailing Lists" in handbook: crossref:handbook/eresources[eresources-mail, Mailing lists].
+These are also published as SSHFP records in DNS.
[[svn]]
== Using Subversion
@@ -784,13 +431,6 @@ After March 2021, subversion use is only for legacy branches (`stable/11` and `s
This section demonstrates how to install Subversion on a FreeBSD system and use it to create a local copy of a FreeBSD repository. Additional information on the use of Subversion is included.
-[[svn-ssl-certificates]]
-=== Root SSL Certificates
-
-FreeBSD systems older than 12._x_ do not have proper root certificates.
-Those certificates allow Subversion to verify the identity of HTTPS repository servers.
-Installation instructions are described in <<git-ssl-certificates>>.
-
[[svn-svnlite]]
=== Svnlite
@@ -905,125 +545,28 @@ HTTPS is the preferred protocol, but the [.filename]#security/ca_root_nss# packa
For other information about using Subversion, please see the "Subversion Book", titled http://svnbook.red-bean.com/[Version Control with Subversion], or the http://subversion.apache.org/docs/[Subversion Documentation].
-[[mirrors-rsync]]
-== Using rsync
-
-These sites make FreeBSD available through the rsync protocol.
-The rsync utility transfers only the differences between two sets of files.
-This is useful for mirror sites of the FreeBSD FTP server.
-The rsync suite is available for many operating systems, on FreeBSD, see the package:net/rsync[] port or use the package.
-
-Czech Republic::
-rsync://ftp.cz.FreeBSD.org/
-+
-Available collections:
-
-** ftp: A partial mirror of the FreeBSD FTP server.
-** FreeBSD: A full mirror of the FreeBSD FTP server.
-
-Germany::
-rsync://rsync3.de.FreeBSD.org/freebsd/
-
-Netherlands::
-rsync://ftp.nl.FreeBSD.org/
-+
-Available collections:
-
-** FreeBSD: A full mirror of the FreeBSD FTP server.
-
-Russia::
-rsync://ftp.mtu.ru/
-+
-Available collections:
-
-** FreeBSD: A full mirror of the FreeBSD FTP server.
-** FreeBSD-Archive: The mirror of FreeBSD Archive FTP server.
-
-Sweden::
-rsync://ftp4.se.freebsd.org/
-+
---
-Available collections:
-
-** FreeBSD: A full mirror of the FreeBSD FTP server.
---
-+
-{mirrors-sweden-ftp2-rsync}
-+
-{mirrors-sweden-ftp4-rsync}
-+
-{mirrors-sweden-ftp4-rsyncv6}
-
-Taiwan::
-rsync://ftp.tw.FreeBSD.org/
-+
-rsync://ftp2.tw.FreeBSD.org/
-+
-rsync://ftp6.tw.FreeBSD.org/
-+
-Available collections:
-
-** FreeBSD: A full mirror of the FreeBSD FTP server.
-
-Ukraine::
-{mirrors-ukraine-ftp6-rsync}
-
-United Kingdom::
-rsync://rsync.mirrorservice.org/
-+
---
-Available collections:
-
-** ftp.freebsd.org: A full mirror of the FreeBSD FTP server.
---
-+
-{mirrors-uk-ftp2-rsync}
-
-United States of America::
-rsync://ftp-master.FreeBSD.org/
-+
-This server may only be used by FreeBSD primary mirror sites.
-+
-Available collections:
-+
---
-** FreeBSD: The master archive of the FreeBSD FTP server.
-** acl: The FreeBSD master ACL list.
---
-+
-rsync://ftp13.FreeBSD.org/
-+
-Available collections:
-
-** FreeBSD: A full mirror of the FreeBSD FTP server.
-
[[mirrors-cdrom]]
== CD and DVD Sets
FreeBSD CD and DVD sets are available from several online retailers:
* FreeBSD Mall, Inc. +
-2420 Sand Creek Rd C-1 #347 +
+1164 Claremont Dr +
Brentwood, CA +
94513 +
USA +
Phone: +1 925 240-6652 +
Fax: +1 925 674-0821 +
-Email: <info@freebsdmall.com> +
+Email: info@freebsdmall.com +
WWW: https://www.freebsdmall.com
* Getlinux +
-78 Rue de la Croix Rochopt +
-Épinay-sous-Sénart +
-91860 +
-France +
-Email: <contact@getlinux.fr> +
-WWW: http://www.getlinux.fr/
+WWW: https://www.getlinux.fr/
* Dr. Hinner EDV +
-Kochelseestr. 11 +
+Schäftlarnstr. 10 // 4. Stock +
D-81371 München +
Germany +
-Phone: (0177) 428 419 0 +
-Email: <infow@hinner.de> +
+Phone: +49 171 417 544 6 +
+Email: infow@hinner.de +
WWW: http://www.hinner.de/linux/freebsd.html
diff --git a/documentation/content/en/books/handbook/multimedia/_index.adoc b/documentation/content/en/books/handbook/multimedia/_index.adoc
index 5a8330276c..37d7669dc8 100644
--- a/documentation/content/en/books/handbook/multimedia/_index.adoc
+++ b/documentation/content/en/books/handbook/multimedia/_index.adoc
@@ -52,7 +52,7 @@ endif::[]
== Synopsis
FreeBSD supports a wide variety of sound cards, allowing users to enjoy high fidelity output from a FreeBSD system.
-This includes the ability to record and play back audio in the MPEG Audio Layer 3 (`MP3`), Waveform Audio File (`WAV`), Ogg Vorbis, and other formats.
+This includes the ability to record and play back audio in the MPEG Audio Layer 3 (`MP3`), Waveform Audio File (`WAV`), Ogg Vorbis, and other formats.
The FreeBSD Ports Collection contains many applications for editing recorded audio, adding sound effects, and controlling attached MIDI devices.
FreeBSD also supports the playback of video files and ``DVD``s.
diff --git a/documentation/content/en/books/handbook/network-servers/_index.adoc b/documentation/content/en/books/handbook/network-servers/_index.adoc
index a028dfa190..1b8d48eb95 100644
--- a/documentation/content/en/books/handbook/network-servers/_index.adoc
+++ b/documentation/content/en/books/handbook/network-servers/_index.adoc
@@ -262,7 +262,7 @@ Some daemons, such as fingerd, can provide information that may be useful to an
Only enable the services which are needed and monitor the system for excessive connection attempts.
`max-connections-per-ip-per-minute`, `max-child` and `max-child-per-ip` can be used to limit such attacks.
-By default, TCP wrappers is enabled.
+By default, TCP wrappers are enabled.
Consult man:hosts_access[5] for more information on placing TCP restrictions on various inetd invoked daemons.
[[network-nfs]]
@@ -476,11 +476,13 @@ This chapter only describes the man:autofs[5] automounter.
The man:autofs[5] facility is a common name for several components that, together, allow for automatic mounting of remote and local filesystems whenever a file or directory within that file system is accessed.
It consists of the kernel component, man:autofs[5], and several userspace applications: man:automount[8], man:automountd[8] and man:autounmountd[8].
It serves as an alternative for man:amd[8] from previous FreeBSD releases.
-Amd is still provided for backward compatibility purposes, as the two use different map format; the one used by autofs is the same as with other SVR4 automounters, such as the ones in Solaris, MacOS X, and Linux.
+amd is still provided for backward compatibility purposes, as the two use different map formats; the one used by autofs is the same as with other SVR4 automounters, such as the ones in Solaris, MacOS X, and Linux.
The man:autofs[5] virtual filesystem is mounted on specified mountpoints by man:automount[8], usually invoked during boot.
-Whenever a process attempts to access file within the man:autofs[5] mountpoint, the kernel will notify man:automountd[8] daemon and pause the triggering process. The man:automountd[8] daemon will handle kernel requests by finding the proper map and mounting the filesystem according to it, then signal the kernel to release blocked process. The man:autounmountd[8] daemon automatically unmounts automounted filesystems after some time, unless they are still being used.
+Whenever a process attempts to access a file within the man:autofs[5] mountpoint, the kernel will notify man:automountd[8] daemon and pause the triggering process.
+The man:automountd[8] daemon will handle kernel requests by finding the proper map and mounting the filesystem according to it, then signal the kernel to release blocked process.
+The man:autounmountd[8] daemon automatically unmounts automounted filesystems after some time, unless they are still being used.
The primary autofs configuration file is [.filename]#/etc/auto_master#. It assigns individual maps to top-level mounts.
For an explanation of [.filename]#auto_master# and the map syntax, refer to man:auto_master[5].
@@ -574,7 +576,7 @@ There are three types of hosts in an NIS environment:
* NIS master server
+
-This server acts as a central repository for host configuration information and maintains the authoritative copy of the files used by all of the NIS clients.
+This server acts as a central repository for host configuration information and maintains the authoritative copy of the files used by all of the NIS clients.
The [.filename]#passwd#, [.filename]#group#, and other various files used by NIS clients are stored on the master server.
While it is possible for one machine to be an NIS master server for more than one NIS domain, this type of configuration will not be covered in this chapter as it assumes a relatively small-scale NIS environment.
* NIS slave servers
@@ -915,7 +917,7 @@ After completing these steps, running `ypcat passwd` on the client should show t
=== NIS Security
Since RPC is a broadcast-based service, any system running ypbind within the same domain can retrieve the contents of the NIS maps.
-To prevent unauthorized transactions, man:ypserv[8] supports a feature called "securenets" which can be used to restrict access to a given set of hosts.
+To prevent unauthorized transactions, man:ypserv[8] supports a feature called "securenets" which can be used to restrict access to a given set of hosts.
By default, this information is stored in [.filename]#/var/yp/securenets#, unless man:ypserv[8] is started with `-p` and an alternate path.
This file contains entries that consist of a network specification and a network mask separated by white space.
Lines starting with `#` are considered to be comments.
@@ -943,7 +945,7 @@ While either access control mechanism adds some security, they are both vulnerab
All NIS-related traffic should be blocked at the firewall.
Servers using [.filename]#securenets# may fail to serve legitimate NIS clients with archaic TCP/IP implementations.
-Some of these implementations set all host bits to zero when doing broadcasts or fail to observe the subnet mask when calculating the broadcast address.
+Some of these implementations set all host bits to zero when doing broadcasts or fail to observe the subnet mask when calculating the broadcast address.
While some of these problems can be fixed by changing the client configuration, other problems may force the retirement of these client systems or the abandonment of [.filename]#securenets#.
The use of TCP Wrapper increases the latency of the NIS server.
@@ -1793,9 +1795,9 @@ The DHCP client keeps a database of valid leases in this file, which is written
=== Installing and Configuring a DHCP Server
This section demonstrates how to configure a FreeBSD system to act as a DHCP server using the Internet Systems Consortium (ISC) implementation of the DHCP server.
-This implementation and its documentation can be installed using the package:net/isc-dhcp43-server[] package or port.
+This implementation and its documentation can be installed using the package:net/isc-dhcp44-server[] package or port.
-The installation of package:net/isc-dhcp43-server[] installs a sample configuration file.
+The installation of package:net/isc-dhcp44-server[] installs a sample configuration file.
Copy [.filename]#/usr/local/etc/dhcpd.conf.example# to [.filename]#/usr/local/etc/dhcpd.conf# and make any edits to this new file.
The configuration file is comprised of declarations for subnets and hosts which define the information that is provided to DHCP clients.
@@ -1872,7 +1874,7 @@ Refer to dhcpd.leases(5), which gives a slightly longer description.
* [.filename]#/usr/local/sbin/dhcrelay#
+
This daemon is used in advanced environments where one DHCP server forwards a request from a client to another DHCP server on a separate network.
-If this functionality is required, install the package:net/isc-dhcp43-relay[] package or port.
+If this functionality is required, install the package:net/isc-dhcp44-relay[] package or port.
The installation includes dhcrelay(8) which provides more detail.
@@ -1960,13 +1962,12 @@ Any existing nameservers in [.filename]#/etc/resolv.conf# will be configured as
If any of the listed nameservers do not support DNSSEC, local DNS resolution will fail.
Be sure to test each nameserver and remove any that fail the test.
The following command will show the trust tree or a failure for a nameserver running on `192.168.1.1`:
-====
-
[source,shell]
....
% drill -S FreeBSD.org @192.168.1.1
....
+====
Once each nameserver is confirmed to support DNSSEC, start Unbound:
@@ -2509,7 +2510,7 @@ The most common settings are `security = share` and `security = user`.
If the clients use usernames that are the same as their usernames on the FreeBSD machine, user level security should be used.
This is the default security policy and it requires clients to first log on before they can access shared resources.
+
-In share level security, clients do not need to log onto the server with a valid username and password before attempting to connect to a shared resource.
+In share level security, clients do not need to log onto the server with a valid username and password before attempting to connect to a shared resource.
This was the default security model for older versions of Samba.
`passdb backend`::
@@ -2586,14 +2587,14 @@ Further documentation can be found in [.filename]#/usr/share/doc/ntp/# in HTML f
=== NTP Configuration
On FreeBSD, the built-in ntpd can be used to synchronize a system's clock.
-Ntpd is configured using man:rc.conf[5] variables and [.filename]#/etc/ntp.conf#, as detailed in the following sections.
+ntpd is configured using man:rc.conf[5] variables and [.filename]#/etc/ntp.conf#, as detailed in the following sections.
-Ntpd communicates with its network peers using UDP packets.
+ntpd communicates with its network peers using UDP packets.
Any firewalls between your machine and its NTP peers must be configured to allow UDP packets in and out on port 123.
==== The [.filename]#/etc/ntp.conf# file
-Ntpd reads [.filename]#/etc/ntp.conf# to determine which NTP servers to query.
+ntpd reads [.filename]#/etc/ntp.conf# to determine which NTP servers to query.
Choosing several NTP servers is recommended in case one of the servers becomes unreachable or its clock proves unreliable.
As ntpd receives responses, it favors reliable servers over the less reliable ones.
The servers which are queried can be local to the network, provided by an ISP, or selected from an http://support.ntp.org/bin/view/Servers/WebHome[ online list of publicly accessible NTP servers].
@@ -2639,13 +2640,13 @@ The descriptions below provide a quick overview of just the keywords used in the
By default, an NTP server is accessible to any network host.
The `restrict` keyword controls which systems can access the server.
Multiple `restrict` entries are supported, each one refining the restrictions given in previous statements.
-The values shown in the example grant the local system full query and control access, while allowing remote systems only the ability to query the time.
+The values shown in the example grant the local system full query and control access, while allowing remote systems only the ability to query the time.
For more details, refer to the `Access Control Support` subsection of man:ntp.conf[5].
The `server` keyword specifies a single server to query.
The file can contain multiple server keywords, with one server listed on each line.
The `pool` keyword specifies a pool of servers.
-Ntpd will add one or more servers from this pool as needed to reach the number of peers specified using the `tos minclock` value.
+ntpd will add one or more servers from this pool as needed to reach the number of peers specified using the `tos minclock` value.
The `iburst` keyword directs ntpd to perform a burst of eight quick packet exchanges with a server when contact is first established, to help quickly synchronize system time.
The `leapfile` keyword specifies the location of a file containing information about leap seconds.
@@ -2673,21 +2674,21 @@ Set `ntpd_oomprotect=YES` to protect the ntpd daemon from being killed by the sy
Set `ntpd_config=` to the location of an alternate [.filename]#ntp.conf# file.
-Set `ntpd_flags=` to contain any other ntpd flags as needed, but avoid using these flags which are managed internally by [.filename]#/etc/rc.d/ntpd#:
+Set `ntpd_flags=` to contain any other ntpd flags as needed, but avoid using these flags which are managed internally by [.filename]#/etc/rc.d/ntpd#:
* `-p` (pid file location)
* `-c` (set `ntpd_config=` instead)
-==== Ntpd and the unpriveleged `ntpd` user
+==== ntpd and the unpriveleged `ntpd` user
-Ntpd on FreeBSD can start and run as an unpriveleged user.
+ntpd on FreeBSD can start and run as an unpriveleged user.
Doing so requires the man:mac_ntpd[4] policy module.
The [.filename]#/etc/rc.d/ntpd# startup script first examines the NTP configuration.
If possible, it loads the `mac_ntpd` module, then starts ntpd as unpriveleged user `ntpd` (user id 123).
To avoid problems with file and directory access, the startup script will not automatically start ntpd as `ntpd` when the configuration contains any file-related options.
-The presence of any of the following in `ntpd_flags` requires manual configuration as described below to run as the `ntpd` user:
+The presence of any of the following in `ntpd_flags` requires manual configuration as described below to run as the `ntpd` user:
* -f or --driftfile
* -i or --jaildir
@@ -2695,7 +2696,7 @@ The presence of any of the following in `ntpd_flags` requires manual configurati
* -l or --logfile
* -s or --statsdir
-The presence of any of the following keywords in [.filename]#ntp.conf# requires manual configuration as described below to run as the `ntpd` user:
+The presence of any of the following keywords in [.filename]#ntp.conf# requires manual configuration as described below to run as the `ntpd` user:
* crypto
* driftfile
@@ -2703,7 +2704,7 @@ The presence of any of the following keywords in [.filename]#ntp.conf# requires
* logdir
* statsdir
-To manually configure ntpd to run as user `ntpd` you must:
+To manually configure ntpd to run as user `ntpd` you must:
* Ensure that the `ntpd` user has access to all the files and directories specified in the configuration.
* Arrange for the `mac_ntpd` module to be loaded or compiled into the kernel. See man:mac_ntpd[4] for details.
diff --git a/documentation/content/en/books/handbook/ports/_index.adoc b/documentation/content/en/books/handbook/ports/_index.adoc
index 074257d4e5..cfe881e847 100644
--- a/documentation/content/en/books/handbook/ports/_index.adoc
+++ b/documentation/content/en/books/handbook/ports/_index.adoc
@@ -201,7 +201,7 @@ Info: Lists information about open files (similar to fstat(1))
Maint: ler@lerctr.org
Index: sysutils
B-deps:
-R-deps:
+R-deps:
....
+
[TIP]
diff --git a/documentation/content/en/books/handbook/preface/_index.adoc b/documentation/content/en/books/handbook/preface/_index.adoc
index 0ef40b5af9..07a2ad9a5d 100644
--- a/documentation/content/en/books/handbook/preface/_index.adoc
+++ b/documentation/content/en/books/handbook/preface/_index.adoc
@@ -295,3 +295,5 @@ In particular, BSDi (subsequently acquired by http://www.windriver.com[Wind Rive
Wind River Systems then paid several additional authors to make a number of improvements to the print-output infrastructure and to add additional chapters to the text.
This work culminated in the publication of the second printed edition in November 2001 (ISBN 1-57176-303-1).
In 2003-2004, http://www.freebsdmall.com[FreeBSD Mall, Inc], paid several contributors to improve the Handbook in preparation for the third printed edition.
+The third printed edition has been split into two volumes.
+Both volumes have been published as The FreeBSD Handbook 3rd Edition Volume 1: User Guide (ISBN 1-57176-327-9) and The FreeBSD Handbook 3rd Edition Volume 2: Administrators Guide (ISBN 1-57176-328-7).
diff --git a/documentation/content/en/books/handbook/printing/_index.adoc b/documentation/content/en/books/handbook/printing/_index.adoc
index 72fdf4f276..39d002377c 100644
--- a/documentation/content/en/books/handbook/printing/_index.adoc
+++ b/documentation/content/en/books/handbook/printing/_index.adoc
@@ -75,11 +75,11 @@ For printing to other types of files, see <<printing-lpd-filters>>.
[.programlisting]
....
lp:\
- :lp=/dev/unlpt0:\ <.>
- :sh:\
- :mx#0:\
- :sd=/var/spool/lpd/lp:\
- :lf=/var/log/lpd-errs:
+lp=/dev/unlpt0:\ <.>
+sh:\
+mx#0:\
+sd=/var/spool/lpd/lp:\
+lf=/var/log/lpd-errs:
....
+
<.> This line is for a printer connected to a `USB` port.
@@ -185,7 +185,7 @@ Network::
Network printers are connected directly to the local computer network.
+
The `DNS` hostname of the printer must be known.
-If the printer is assigned a dynamic address by `DHCP`, `DNS` should be dynamically updated so that the host name always has the correct `IP` address.
+If the printer is assigned a dynamic address by `DHCP`, `DNS` should be dynamically updated so that the host name always has the correct `IP` address.
Network printers are often given static `IP` addresses to avoid this problem.
+
Most network printers understand print jobs sent with the LPD protocol.
@@ -858,7 +858,7 @@ These pages are also sometimes called _banner_ or _separator_ pages.
Enabling header pages differs depending on whether the printer is connected directly to the computer with a `USB`, parallel, or serial cable, or is connected remotely over a network.
-Header pages on directly-connected printers are enabled by removing the `:sh:\` (Suppress Header) line from the entry in [.filename]#/etc/printcap#.
+Header pages on directly-connected printers are enabled by removing the `:sh:\` (Suppress Header) line from the entry in [.filename]#/etc/printcap#.
These header pages only use line feed characters for new lines.
Some printers will need the [.filename]#/usr/share/examples/printing/hpif# filter to prevent stairstepped text.
The filter configures `PCL` printers to print both carriage returns and line feeds when a line feed is received.
diff --git a/documentation/content/en/books/handbook/security/_index.adoc b/documentation/content/en/books/handbook/security/_index.adoc
index 371ddf908e..d7affaa5df 100644
--- a/documentation/content/en/books/handbook/security/_index.adoc
+++ b/documentation/content/en/books/handbook/security/_index.adoc
@@ -87,7 +87,7 @@ A weak entry point in any system could allow intruders to gain access to critica
One of the core principles of information security is the CIA triad, which stands for the Confidentiality, Integrity, and Availability of information systems.
The CIA triad is a bedrock concept of computer security as customers and users expect their data to be protected.
-For example, a customer expects that their credit card information is securely stored (confidentiality), that their orders are not changed behind the scenes (integrity), and that they have access to their order information at all times (availablility).
+For example, a customer expects that their credit card information is securely stored (confidentiality), that their orders are not changed behind the scenes (integrity), and that they have access to their order information at all times (availability).
To provide CIA, security professionals apply a defense in depth strategy.
The idea of defense in depth is to add several layers of security to prevent one single layer failing and the entire security system collapsing.
@@ -175,7 +175,7 @@ Blowfish is not part of AES and is not considered compliant with any Federal Inf
Its use may not be permitted in some environments.
====
-To determine which hash algorithm is used to encrypt a user's password, the superuser can view the hash for the user in the FreeBSD password database.
+To determine which hash algorithm is used to encrypt a user's password, the superuser can view the hash for the user in the FreeBSD password database.
Each hash starts with a symbol which indicates the type of hash mechanism used to encrypt the password.
If DES is used, there is no beginning symbol.
For MD5, the symbol is `$`.
@@ -293,7 +293,7 @@ For more information, see man:pw[8].
A _rootkit_ is any unauthorized software that attempts to gain `root` access to a system.
Once installed, this malicious software will normally open up another avenue of entry for an attacker.
-Realistically, once a system has been compromised by a rootkit and an investigation has been performed, the system should be reinstalled from scratch.
+Realistically, once a system has been compromised by a rootkit and an investigation has been performed, the system should be reinstalled from scratch.
There is tremendous risk that even the most prudent security or systems engineer will miss something an attacker left behind.
A rootkit does do one thing useful for administrators: once detected, it is a sign that a compromise happened at some point.
@@ -441,7 +441,7 @@ Source routing is a method for detecting and accessing non-routable addresses on
This should be disabled as non-routable addresses are normally not routable on purpose.
To disable this feature, set `net.inet.ip.sourceroute` and `net.inet.ip.accept_sourceroute` to `0`.
-When a machine on the network needs to send messages to all hosts on a subnet, an ICMP echo request message is sent to the broadcast address.
+When a machine on the network needs to send messages to all hosts on a subnet, an ICMP echo request message is sent to the broadcast address.
However, there is no reason for an external host to perform such an action.
To reject all external broadcast requests, set `net.inet.icmp.bmcastecho` to `0`.
@@ -565,7 +565,7 @@ FreeBSD/i386 (example.com) (ttypa)
login: <username>
otp-md5 498 gr4269 ext
-Password:
+Password:
....
The OPIE prompts provides a useful feature.
@@ -1143,10 +1143,10 @@ If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:PA
-Locality Name (eg, city) []:Pittsburgh
-Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
-Organizational Unit Name (eg, section) []:Systems Administrator
-Common Name (eg, YOUR name) []:localhost.example.org
+Locality Name (e.g., city) []:Pittsburgh
+Organization Name (e.g., company) [Internet Widgits Pty Ltd]:My Company
+Organizational Unit Name (e.g., section) []:Systems Administrator
+Common Name (e.g., YOUR name) []:localhost.example.org
Email Address []:trhodes@FreeBSD.org
Please enter the following 'extra' attributes
@@ -1190,9 +1190,9 @@ If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:PA
-Locality Name (eg, city) []:Pittsburgh
-Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
-Organizational Unit Name (eg, section) []:Systems Administrator
+Locality Name (e.g., city) []:Pittsburgh
+Organization Name (e.g., company) [Internet Widgits Pty Ltd]:My Company
+Organizational Unit Name (e.g., section) []:Systems Administrator
Common Name (e.g. server FQDN or YOUR name) []:localhost.example.org
Email Address []:trhodes@FreeBSD.org
....
@@ -1300,7 +1300,13 @@ In the example scenario:
* Both sites are connected to the Internet through a gateway that is running FreeBSD.
* The gateway on each network has at least one external IP address. In this example, the corporate LAN's external IP address is `172.16.5.4` and the home LAN's external IP address is `192.168.1.12`.
-* The internal addresses of the two networks can be either public or private IP addresses. However, the address space must not collide. For example, both networks cannot use `192.168.1.x`. In this example, the corporate LAN's internal IP address is `10.246.38.1` and the home LAN's internal IP address is `10.0.0.5`.
+* The internal addresses of the two networks can be either public or private IP addresses. However, the address space must not overlap. In this example, the corporate LAN's internal IP address is `10.246.38.1` and the home LAN's internal IP address is `10.0.0.5`.
+
+[.programlisting]
+....
+ corporate home
+10.246.38.1/24 -- 172.16.5.4 <--> 192.168.1.12 -- 10.0.0.5/24
+....
=== Configuring a VPN on FreeBSD
@@ -1308,17 +1314,24 @@ To begin, package:security/ipsec-tools[] must be installed from the Ports Collec
This software provides a number of applications which support the configuration.
The next requirement is to create two man:gif[4] pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly.
-As `root`, run the following commands, replacing _internal_ and _external_ with the real IP addresses of the internal and external interfaces of the two gateways:
+As `root`, run the following command on each gateway:
+
+[source,shell]
+....
+corp-gw# ifconfig gif0 create
+corp-gw# ifconfig gif0 10.246.38.1 10.0.0.5
+corp-gw# ifconfig gif0 tunnel 172.16.5.4 192.168.1.12
+....
[source,shell]
....
-# ifconfig gif0 create
-# ifconfig gif0 internal1 internal2
-# ifconfig gif0 tunnel external1 external2
+home-gw# ifconfig gif0 create
+home-gw# ifconfig gif0 10.0.0.5 10.246.38.1
+home-gw# ifconfig gif0 tunnel 192.168.1.12 172.16.5.4
....
-Verify the setup on each gateway, using `ifconfig`.
-Here is the output from Gateway 1:
+Verify the setup on each gateway, using `ifconfig gif0`.
+Here is the output from the home gateway:
[.programlisting]
....
@@ -1328,7 +1341,7 @@ inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00
....
-Here is the output from Gateway 2:
+Here is the output from the corporate gateway:
[.programlisting]
....
@@ -1342,7 +1355,7 @@ Once complete, both internal IP addresses should be reachable using man:ping[8]:
[source,shell]
....
-priv-net# ping 10.0.0.5
+home-gw# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
@@ -1352,7 +1365,7 @@ PING 10.0.0.5 (10.0.0.5): 56 data bytes
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms
-corp-net# ping 10.246.38.1
+corp-gw# ping 10.246.38.1
PING 10.246.38.1 (10.246.38.1): 56 data bytes
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
@@ -1365,48 +1378,44 @@ round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms
....
As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses.
-Next, both gateways must be told how to route packets in order to correctly send traffic from either network.
+Next, both gateways must be told how to route packets in order to correctly send traffic from the networks behind each gateway.
The following commands will achieve this goal:
[source,shell]
....
-corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0
-corp-net# route add net 10.0.0.0: gateway 10.0.0.5
-priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0
-priv-net# route add host 10.246.38.0: gateway 10.246.38.1
+corp-gw# route add 10.0.0.0 10.0.0.5 255.255.255.0
+corp-gw# route add net 10.0.0.0: gateway 10.0.0.5
+home-gw# route add 10.246.38.0 10.246.38.1 255.255.255.0
+home-gw# route add host 10.246.38.0: gateway 10.246.38.1
....
-At this point, internal machines should be reachable from each gateway as well as from machines behind the gateways.
+Internal machines should be reachable from each gateway as well as from machines behind the gateways.
Again, use man:ping[8] to confirm:
[source,shell]
....
-corp-net# ping 10.0.0.8
+corp-gw# ping -c 3 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
-64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
-64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
--- 10.0.0.8 ping statistics ---
-5 packets transmitted, 5 packets received, 0% packet loss
+3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms
-priv-net# ping 10.246.38.107
+home-gw# ping -c 3 10.246.38.107
PING 10.246.38.1 (10.246.38.107): 56 data bytes
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
-64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
-64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
--- 10.246.38.107 ping statistics ---
-5 packets transmitted, 5 packets received, 0% packet loss
+3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms
....
-Setting up the tunnels is the easy part. Configuring a secure link is a more in depth process.
-The following configuration uses pre-shared (PSK) RSA keys.
-Other than the IP addresses, the [.filename]#/usr/local/etc/racoon/racoon.conf# on both gateways will be identical and look similar to:
+At this point, traffic is flowing between the networks encapsulated in a gif tunnel but without any encryption.
+Next, use IPSec to encrypt traffic using pre-shared keys (PSK).
+Other than the IP addresses, [.filename]#/usr/local/etc/racoon/racoon.conf# on both gateways will be identical and look similar to:
[.programlisting]
....
@@ -1496,7 +1505,7 @@ The output should be similar to the following:
[source,shell]
....
-corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
+corp-gw# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
@@ -1510,12 +1519,12 @@ Foreground mode.
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
....
-To ensure the tunnel is working properly, switch to another console and use man:tcpdump[1] to view network traffic using the following command.
+To ensure the tunnel is working properly, switch to another console and use man:tcpdump[1] to view network traffic using the following command.
Replace `em0` with the network interface card as required:
[source,shell]
....
-# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12
+corp-gw# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12
....
Data similar to the following should appear on the console.
@@ -1836,7 +1845,7 @@ This will start sshd, the daemon program for OpenSSH, the next time the system b
# service sshd start
....
-The first time sshd starts on a FreeBSD system, the system's host keys will be automatically created and the fingerprint will be displayed on the console.
+The first time sshd starts on a FreeBSD system, the system's host keys will be automatically created and the fingerprint will be displayed on the console.
Provide users with the fingerprint so that they can verify it the first time they connect to the server.
Refer to man:sshd[8] for the list of available options when starting sshd and a more complete discussion about authentication, the login process, and the various configuration files.
@@ -2141,7 +2150,7 @@ Restart the applicable daemons, or reboot the system.
3) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
-platforms can be updated via the freebsd-update(8) utility:
+platforms can be updated via the man:freebsd-update[8] utility:
# freebsd-update fetch
# freebsd-update install
diff --git a/documentation/content/en/books/handbook/serialcomms/_index.adoc b/documentation/content/en/books/handbook/serialcomms/_index.adoc
index 646527c552..8c62ad814c 100644
--- a/documentation/content/en/books/handbook/serialcomms/_index.adoc
+++ b/documentation/content/en/books/handbook/serialcomms/_index.adoc
@@ -81,7 +81,7 @@ Data Terminal Equipment (DTE) is one of two endpoints in a serial communication.
An example would be a computer.
DCE::
-Data Communications Equipment (DTE) is the other endpoint in a serial communication.
+Data Communications Equipment (DCE) is the other endpoint in a serial communication.
Typically, it is a modem or serial terminal.
RS-232::
diff --git a/documentation/content/en/books/handbook/usb-device-mode/_index.adoc b/documentation/content/en/books/handbook/usb-device-mode/_index.adoc
index 11c65d34fb..ba62cedfc5 100644
--- a/documentation/content/en/books/handbook/usb-device-mode/_index.adoc
+++ b/documentation/content/en/books/handbook/usb-device-mode/_index.adoc
@@ -140,7 +140,7 @@ To load the module and set the template without rebooting use:
To connect to a board configured to provide USB device mode serial ports, connect the USB host, such as a laptop, to the boards USB OTG or USB client port.
Use `pstat -t` on the host to list the terminal lines.
-Near the end of the list you should see a USB serial port, eg "ttyU0".
+Near the end of the list you should see a USB serial port, e.g. "ttyU0".
To open the connection, use:
[source,shell]
@@ -240,7 +240,7 @@ The cfumass startup script sets the correct template number automatically when s
=== Configuring USB Mass Storage Using Other Means
The rest of this chapter provides detailed description of setting the target without using the cfumass rc file.
-This is necessary if eg one wants to provide a writeable LUN.
+This is necessary if e.g. one wants to provide a writeable LUN.
USB Mass Storage does not require the man:ctld[8] daemon to be running, although it can be used if desired.
This is different from iSCSI.
diff --git a/documentation/content/en/books/handbook/wine/_index.adoc b/documentation/content/en/books/handbook/wine/_index.adoc
index 1dd20c0c35..7b1aff26a2 100644
--- a/documentation/content/en/books/handbook/wine/_index.adoc
+++ b/documentation/content/en/books/handbook/wine/_index.adoc
@@ -158,7 +158,7 @@ While Steam does not offer a native FreeBSD client,there are several options for
[[wine-companion-programs]]
==== WINE Companion Programs
-In addition to proprietary offerings, other projects have released applications designed to work in tandem with the standard, open source version of WINE.
+In addition to proprietary offerings, other projects have released applications designed to work in tandem with the standard, open source version of WINE.
The goals for these can range from making installation easier to offering easy ways to get popular software installed.
These solutions are covered in greater detail in the later section on <<wine-management-guis,GUI frontends>>, and include the following:
@@ -256,30 +256,14 @@ Alternately compile the WINE sub-system from source with the following:
=== Concerns of 32- Versus 64-Bit in WINE Installations
Like most software, Windows(R) applications made the upgrade from the older 32-bit architecture to 64 bits.
-And most recent software is written for 64-bit operating systems, although modern OSes can sometimes continue to run older 32-bit programs as well.
+And most recent software is written for 64-bit operating systems, although modern OSes can sometimes continue to run older 32-bit programs as well.
FreeBSD is no different, having had support for 64-bit since the 5.x series.
However, using old software no longer supported by default is a common use for emulators, and users commonly turn to WINE to play games and use other programs that do not run properly on modern hardware.
Fortunately, FreeBSD can support all three scenarios:
* On modern, 64-bit machine and want to run 64-bit Windows(R) software, simply install the ports mentioned in the above sections. The ports system will automatically install the 64-bit version.
-* Alternately, users might have an older 32-bit machine that they do not want to run with its original, now non-supported software. They can install the 32-bit (i386) version of FreeBSD, then install the ports in the above sections. Again, on a 32-bit machine the ports system will install the corresponding 32-bit version of WINE by default.
-
-However, given a 64-bit version of FreeBSD and need to run *32-bit* Windows(R) applications, installing a different port is required to enable 32-bit compatibility.
-To install the pre-compiled package, use the following:
-
-[source,shell]
-....
-# pkg install i386-wine
-....
-
-Or compile the port with the following:
-
-[source,shell]
-....
-# cd /usr/ports/emulator/i386-wine
-# make install
-....
+* Alternately, users might have an older 32-bit machine that they do not want to run with its original, now non-supported software. They can install the 32-bit (i386) version of FreeBSD, then install the ports in the above sections.
[[running-first-wine-program]]
== Running a First WINE Program on FreeBSD
@@ -320,7 +304,7 @@ Alternately, supply the full path to the executable to use it in a script, for e
After installation graphical shells should be updated with new associations for Windows executable ([.filename]#.EXE#) files.
It will now be possible to browse the system using a file manager, and launch the Windows application in the same way as other files and programs (either a single- or double-click, depending on the desktop's settings).
-On most desktops, check to make sure this association is correct by right-clicking on the file, and looking for an entry in the context menu to open the file.
+On most desktops, check to make sure this association is correct by right-clicking on the file, and looking for an entry in the context menu to open the file.
One of the options (hopefully the default one) will be with the *Wine Windows Program Loader*, as shown in the below screenshot:
image::wine-run-np++-1.png[]
@@ -490,7 +474,7 @@ It also allows entry of (entirely optional) user information, although this is n
[[wine-management-guis]]
== WINE Management GUIs
-While the base install of WINE comes with a GUI configuration tool in winecfg, it is main purpose is just that: strictly configuring an existing WINE prefix.
+While the base install of WINE comes with a GUI configuration tool in winecfg, it is main purpose is just that: strictly configuring an existing WINE prefix.
There are, however, more advanced applications that will assist in the initial installation of applications as well as optimizing their WINE environments.
The below sections include a selection of the most popular.
@@ -685,13 +669,13 @@ But the expectation is that only one will be using the physical machine (a deskt
More recent consumer versions of Windows(R) have taken some steps to improve the OS in multi-user scenarios.
But it is still largely structured around a single-user experience.
-Furthermore, the measures the WINE project has taken to create acompatible environment means, unlike FreeBSD applications (including WINE itself), it will resemble this single-user environment.
+Furthermore, the measures the WINE project has taken to create a compatible environment means, unlike FreeBSD applications (including WINE itself), it will resemble this single-user environment.
So it follows that each user will have to maintain their own set of configurations, which is potentially good.
Yet it is advantageous to install applications, particularly large ones like office suites or games, only once.
Two examples of reasons to do this are maintenance (software updates need only be applied once) and efficiency in storage (no duplicated files).
-There are two strategies to minimze the impact of multiple WINE users in the system.
+There are two strategies to minimize the impact of multiple WINE users in the system.
[[installing-applications-to-a-common-drivesettings]]
=== Installing Applications to a Common Drive
@@ -727,7 +711,7 @@ Create a new user with the following command (as root), which will step through
....
Enter the username (e.g., _windows_) and Full name ("Microsoft Windows").
-Then accept the defaults for the remainder of the questions. Next, install the sudo utlity using binary packages with the following:
+Then accept the defaults for the remainder of the questions. Next, install the sudo utility using binary packages with the following:
[source,shell]
....
@@ -803,7 +787,7 @@ However, multiple installs can be achieved using mechanisms like chroots/jails,
[[can-dos-programs-be-run-on-wine]]
==== Can DOS Programs Be Run on WINE?
-They can, as "Console User Interface" applications as mentioned eariler in this section.
+They can, as "Console User Interface" applications as mentioned earlier in this section.
However, there is an arguably better method for running DOS software: DOSBox.
On the other hand, there's little reason not to at least try it.
Simply create a new prefix, install the software, and if it does not work delete the prefix.
@@ -858,7 +842,7 @@ According to https://forums.freebsd.org/threads/make-wine-ui-fonts-look-good.682
==== Does Having Windows(R) Installed Elsewhere on a System Help WINE Operate?
It may, depending on the application being run.
-As mentioned in the section describing winecfg, some built-in WINE DLLs and other libraries can be overridden by providing a path to an alternate version.
+As mentioned in the section describing winecfg, some built-in WINE DLLs and other libraries can be overridden by providing a path to an alternate version.
Provided the Windows(R) partition or drive is mounted to the FreeBSD system and accessible to the user, configuring some of these overrides will use native Windows(R) libraries and may decrease the chance of unexpected behavior.
[[application-specific]]
@@ -867,7 +851,7 @@ Provided the Windows(R) partition or drive is mounted to the FreeBSD system and
[[where-is-the-best-place-to-see-if-application-x-works-on-wine]]
==== Where is the Best Place to see if Application X Works on WINE?
-The first stop in determining compatibiliy should be the https://appdb.winehq.org/[WINE AppDB].
+The first stop in determining compatibility should be the https://appdb.winehq.org/[WINE AppDB].
This is a compilation of reports of programs working (or not) on all supported platforms, although (as previously mentioned), solutions for one platform are often applicable to others.
[[is-there-anything-that-will-help-games-run-better]]
diff --git a/documentation/content/en/books/handbook/x11/_index.adoc b/documentation/content/en/books/handbook/x11/_index.adoc
index cda692d10a..7abc40e5f8 100644
--- a/documentation/content/en/books/handbook/x11/_index.adoc
+++ b/documentation/content/en/books/handbook/x11/_index.adoc
@@ -954,7 +954,7 @@ XDM will run on the ninth virtual terminal by default.
The XDM configuration directory is located in [.filename]#/usr/local/etc/X11/xdm#.
This directory contains several files used to change the behavior and appearance of XDM, as well as a few scripts and programs used to set up the desktop when XDM is running.
<<xdm-config-files>> summarizes the function of each of these files.
-The exact syntax and usage of these files is described in man:xdm[1].
+The exact syntax and usage of these files is described in man:xdm[8].
[[xdm-config-files]]
.XDM Configuration Files
@@ -1003,7 +1003,7 @@ DisplayManager.requestPort: 0
....
Save the edits and restart XDM.
-To restrict remote access, look at the example entries in [.filename]#/usr/local/etc/X11/xdm/Xaccess# and refer to man:xdm[1] for further information.
+To restrict remote access, look at the example entries in [.filename]#/usr/local/etc/X11/xdm/Xaccess# and refer to man:xdm[8] for further information.
[[x11-wm]]
== Desktop Environments
@@ -1024,7 +1024,7 @@ This desktop environment can be installed from a package:
[source,shell]
....
-# pkg install gnome3
+# pkg install gnome
....
To instead build GNOME from ports, use the following command.
@@ -1032,7 +1032,7 @@ GNOME is a large application and will take some time to compile, even on a fast
[source,shell]
....
-# cd /usr/ports/x11/gnome3
+# cd /usr/ports/x11/gnome
# make install clean
....
@@ -1170,7 +1170,7 @@ Once KDE Plasma is started, refer to its built-in help system for more informati
Xfce is a desktop environment based on the GTK+ toolkit used by GNOME.
However, it is more lightweight and provides a simple, efficient, easy-to-use desktop.
-It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable.
+It is fully configurable, has a main panel with menus, applets, and application launchers, provides a file manager and sound manager, and is themeable.
Since it is fast, light, and efficient, it is ideal for older or slower machines with memory limitations.
More information on Xfce can be found at http://www.xfce.org/[http://www.xfce.org].
@@ -1535,7 +1535,7 @@ This is typically [.filename]#/etc/X11/xorg.conf# or [.filename]#/usr/local/etc/
The Xorg configuration process is now complete.
Xorg may be now started with the man:startx[1] utility.
-The Xorg server may also be started with the use of man:xdm[1].
+The Xorg server may also be started with the use of man:xdm[8].
=== Configuration with Intel(R) `i810` Graphics Chipsets
@@ -1552,7 +1552,7 @@ This section assumes a bit of advanced configuration knowledge.
If attempts to use the standard configuration tools above have not resulted in a working configuration, there is information enough in the log files to be of use in getting the setup working.
Use of a text editor will be necessary.
-Current widescreen (WSXGA, WSXGA+, WUXGA, WXGA, WXGA+, et.al.) formats support 16:10 and 10:9 formats or aspect ratios that can be problematic.
+Current widescreen (WSXGA, WSXGA+, WUXGA, WXGA, WXGA+, et.al.) formats support 16:10 and 10:9 formats or aspect ratios that can be problematic.
Examples of some common screen resolutions for 16:10 aspect ratios are:
* 2560x1600
@@ -1640,3 +1640,641 @@ The most common would be:
This is usually the case when you upgrade Xorg.
You will need to reinstall the package:x11/nvidia-driver[] package so glx is built again.
+
+[[x-wayland]]
+== Wayland on FreeBSD
+Wayland is a new software for supporting graphical user interfaces, but it differs from Xorg in several important ways.
+First, Wayland is only a protocol that acts as an intermediary between clients using a different mechanism which removes the dependency on an X server.
+Xorg includes both the X11 protocol, used to run remote displays and the X server will accept connections and display windows.
+Under Wayland, the compositor or window manager provides the display server instead of a traditional X server.
+
+Since Wayland is not an X server, traditional X screen connections will need to utilize other methods such as VNC or RDP for remote desktop management. Second, Wayland can manage composite communications between clients and a compositor as a separate entity which does not need to support the X protocols.
+
+Wayland is relatively new, and not all software has been updated to run natively without `Xwayland` support.
+Because Wayland does not provide the X server, and expects compositors to provide that support, X11 window managers that do not yet support Wayland will require that `Xwayland` is not started with the `-rootless` parameter.
+The `-rootless` parameter, when removed, will restore X11 window manager support.
+
+[NOTE]
+====
+The current NVidia driver should work with most wl-roots compositors, but it may be a little unstable and not support all features at this time.
+Volunteers to help work on the NVidia DRM are requested.
+====
+
+Currently, a lot of software will function with minimal issues on Wayland, including Firefox.
+And a few desktops are also available, such as the Compiz Fusion replacement, known as Wayfire, and the i3 window manager replacement, Sway.
+
+[NOTE]
+====
+As of May, 2021, plasma5-kwin does support Wayland on FreeBSD.
+To use Plasma under Wayland, use the `startplasma-wayland` parameter to `ck-launch-session` and tie in dbus with:
+`ck-launch-session dbus-run-session startplasma-wayland`
+to get it working.
+====
+
+For compositors, a kernel supporting the man:evdev[4] driver must exist to utilize the keybinding functionality.
+This is built into the [.filename]#GENERIC# kernel by default; however, if it has been customized and man:evdev[4] support was stripped out, the man:evdev[4] module will need to be loaded.
+In addition, users of `Wayland` will need to be members of the `video` group.
+To quickly make this change, use the `pw` command:
+
+[source,shell]
+----
+pw groupmod video -m user
+----
+
+Installing Wayland is simple; there is not a great deal of configuration for the protocol itself.
+Most of the composition will depend on the chosen compositor.
+By installing `seatd` now, a step is skipped as part of the compositor installation and configuration as `seatd` is needed to provide non-root access to certain devices.
+All of the compositors described here should work with package:graphics/drm-kmod[] open source drivers; however, the NVidia graphics cards may have issues when using the proprietary drivers.
+Begin by installing the following packages:
+
+[source,shell]
+----
+# pkg install wayland seatd
+----
+
+Once the protocol and supporting packages have been installed, a compositor must create the user interface.
+Several compositors will be covered in the following sections.
+All compositors using Wayland will need a runtime directory defined in the environment, which can be achieved with the following command in the bourne shell:
+
+[source,shell]
+----
+% export XDG_RUNTIME_DIR=/var/run/user/`id -u`
+----
+
+It is important to note that most compositors will search the XDG_RUNTIME_DIR directory for the configuration files.
+In the examples included here, a parameter will be used to specify a configuration file in [.filename]#~/.config# to keep temporary files and configuration files separate.
+It is recommended that an alias be configured for each compositor to load the designated configuration file.
+
+[WARNING]
+====
+It has been reported that ZFS users may experience issues with some Wayland clients because they need access to `posix_fallocate()` in the runtime directory.
+While the author could not reproduce this issue on their ZFS system, a recommended workaround is not to use ZFS for the runtime directory and instead use `tmpfs` for the [.filename]#/var/run# directory.
+In this case, the `tmpfs` file system is used for [.filename]#/var/run# and mounted through the command `mount -t tmpfs tmpfs /var/run` command and then make this change persist across reboots through [.filename]#/etc/fstab#.
+The XDG_RUNTIME_DIR environment variable could be configured to use [.filename]#/var/run/user/$UID# and avoid potential pitfalls with ZFS.
+Consider that scenario when reviewing the configuration examples in the following sections.
+====
+
+The seatd daemon helps manage access to shared system devices for non-root users in compositors; this includes graphics cards.
+For traditional X11 managers, `seatd` is not needed, such as both Plasma and GNOME, but for the Wayland compositors discussed here, it will need enabled on the system and be running before starting a compositor environment.
+To enable and start the `seatd` daemon now, and on system initialization:
+
+[source,shell]
+----
+# sysrc seatd_enable="YES"
+# service seatd start
+----
+
+Afterward, a compositor, which is similar to an X11 desktop, will need to be installed for the GUI environment.
+Three are discussed here, including basic configuration options, setting up a screen lock, and recommendations for more information.
+
+=== The Wayfire Compositor
+
+Wayfire is a compositor that aims to be lightweight and customizable.
+Several features are available, and it brings back several elements from the previously released Compiz Fusion desktop.
+All of the parts look beautiful on modern hardware. To get Wayfire up and running, begin by installing the required packages:
+
+[source,shell]
+----
+# pkg install wayfire wf-shell alacritty swaylock-effects swayidle wlogout kanshi mako wlsunset
+----
+
+The `alacritty` package provides a terminal emulator.
+Still, it is not completely required as other terminal emulators such as `kitty`, and XFCE-4 `Terminal` have been tested and verified to work under the Wayfire compositor.
+Wayfire configuration is relatively simple; it uses a file that should be reviewed for any customizations.
+To begin, copy the example file over to the runtime environment configuration directory and then edit the file:
+
+[source,shell]
+----
+% mkdir ~/.config/wayfire
+% cp /usr/local/share/examples/wayfire/wayfire.ini ~/.config/wayfire
+----
+
+The defaults for most users should be fine.
+Within the configuration file, items like the famous `cube` are pre-configured, and there are instructions to help with the available settings.
+A few primary settings of note include:
+
+[.programlisting]
+....
+[output]
+mode = 1920x1080@60000
+position = 0,0
+transform = normal
+scale = 1.000000
+....
+
+In this example, from the configuration file, the screen's output should be the listed mode at the listed hertz.
+For example, the mode should be set to `widthxheight@refresh_rate`.
+The position places the output at a specific pixel location specified.
+The default should be fine for most users.
+Finally, transform sets a background transform, and scale will scale the output to the specified scale factor.
+The defaults for these options are generally acceptable; for more information, see the documentation.
+
+As mentioned, Wayland is new, and not all applications work with the protocol yet.
+At this time, `sddm` does not appear to support starting and managing compositors in Wayland.
+The `swaylock` utility has been used instead in these examples. The configuration file contains options to run `swayidle` and `swaylock` for idle and locking of the screen.
+This option to define the action to take when the system is idle is listed as:
+
+[.programlisting]
+....
+idle = swaylock
+....
+
+And the lock timeout is configured using the following lines:
+
+[.programlisting]
+....
+[idle]
+toggle = <super> KEY_Z
+screensaver_timeout = 300
+dpms_timeout = 600
+....
+
+The first option will lock the screen after 300 seconds, and after another 300, the screen will shut off through the `dpms_timeout` option.
+
+One final thing to note is the <super> key.
+Most of the configuration mentions this key, and it is the traditional `Windows` key on the keyboard.
+Most keyboards have this super key available; however, it should be remapped within this configuration file if it is not available.
+For example, to lock the screen, press and hold the super key, the kbd:[shift] key, and press the kbd:[escape] key.
+nless the mappings have changed, this will execute the swaylock application.
+The default configuration for `swaylock` will show a grey screen; however, the application is highly customizable and well documented.
+In addition, since the swaylock-effects is the version that was installed, there are several options available such as the blur effect, which can be seen using the following command:
+
+[source,shell]
+----
+% swaylock --effect-blur 7x5
+----
+
+There is also the `--clock` parameter which will display a clock with the date and time on the lock screen.
+When package:x11/swaylock-effects[] was installed, a default [.filename]#pam.d# configuration was included.
+It provides the default options that should be fine for most users.
+More advanced options are available; see the PAM documentation for more information.
+
+At this point, it is time to test Wayfire and see if it can start up on the system.
+Just type the following command:
+
+[source,shell]
+----
+% wayfire -c ~/.config/wayfire/wayfire.ini
+----
+
+The compositor should now start and display a background image along with a menu bar at the top of the screen.
+Wayfire will attempt to list installed compatible applications for the desktop and present them in this drop-down menu; for example, if the XFCE-4 file manager is installed, it will show up in this drop-down menu.
+If a specific application is compatible and valuable enough for a keyboard shortcut, it may be mapped to a keyboard sequence using the [.filename]#wayfire.ini# configuration file.
+Wayfire also has a configuration tool named Wayfire Config Manager.
+It is located in the drop-down menu bar but may also be started through a terminal by issuing the following command:
+
+[source,shell]
+----
+% wcm
+----
+
+Various Wayfire configuration options, including the composite special effects, maybe enabled, disabled, or configured through this application.
+In addition, for a more user-friendly experience, a background manager, panel, and docking application may be enabled in the configuration file:
+
+[.programlisting]
+....
+panel = wf-panel
+dock = wf-dock
+background = wf-background
+....
+
+[WARNING]
+====
+Changes made through `wcm` will overwrite custom changes in the [.filename]#wayfire.ini# configuration file.
+The [.filename]#wayfire.ini# file is highly recommended to be backed up so any essential changes may be restored.
+====
+
+Finally, the default launcher listed in the [.filename]#wayfire.ini# is package:x11/wf-shell[] which may be replaced with other panels if desired by the user.
+
+=== The Hikari Compositor
+
+The Hikari compositor uses several concepts centered around productivity, such as sheets, workspaces, and more.
+In that way, it resembles a tiling window manager.
+Breaking this down, the compositor starts with a single workspace, which is similar to virtual desktops.
+Hikari uses a single workspace or virtual desktop for user interaction. The workspace is made up of several views, which are the working windows in the compositor grouped as either sheets or groups.
+Both sheets and groups are made up of a collection of views; again, the windows that are grouped together.
+When switching between sheets or groups, the active sheet or group will become known collectively as the workspace.
+The manual page will break this down into more information on the functions of each but for this document, just consider a single workspace utilizing a single sheet.
+Hikari installation will comprise of a single package, package:x11-wm/hikari[], and a terminal emulator `alacritty`:
+
+[source,shell]
+----
+# pkg install hikari alacritty
+----
+
+[NOTE]
+====
+Other shells, such as `kitty` or the Plasma `Terminal`, will function under Wayland. Users should experiment with their favorite terminal editor to validate compatibility.
+====
+
+Hikari uses a configuration file, [.filename]#hikari.conf#, which could either be placed in the XDG_RUNTIME_DIR or specified on startup using the `-c` parameter.
+An autostart configuration file is not required but may make the migration to this compositor a little easier.
+Beginning the configuration is to create the Hikari configuration directory and copy over the configuration file for editing:
+
+[source,shell]
+----
+% mkdir ~/.config/hikari
+% cp /usr/local/etc/hikari/hikari.conf ~/.config/hikari
+----
+
+The configuration is broken out into various stanzas such as ui, outputs, layouts, and more.
+For most users, the defaults will function fine; however, some important changes should be made.
+For example, the $TERMINAL variable is normally not set within the user's environment.
+Changing this variable or altering the [.filename]#hikari.conf# file to read:
+
+[.programlisting]
+....
+terminal = "/usr/local/bin/alacritty"
+....
+
+Will launch the `alacritty` terminal using the bound key press.
+While going through the configuration file, it should be noted that the capital letters are used to map keys out for the user.
+For example, the kbd:[L] key for starting the terminal kbd:[L+Return] is actually the previously discussed super key or Windows logo key.
+Therefore, holding the kbd:[L/super/Windows] key and pressing kbd:[Enter] will open the specified terminal emulator with the default configuration.
+Mapping other keys to applications require an action definition to be created.
+For this, the action item should be listed in the actions stanza, for example:
+
+[.programlisting]
+....
+actions {
+ terminal = "/usr/local/bin/alacritty"
+ browser = "/usr/local/bin/firefox"
+}
+....
+
+Then an action may be mapped under the keyboard stanza, which is defined within the bindings stanza:
+
+[.programlisting]
+....
+bindings {
+ keyboard {
+SNIP
+ "L+Return" = action-terminal
+ "L+b" = action-browser
+SNIP
+....
+
+After Hikari is restarted, holding the Windows logo button and pressing the kbd:[b] key on the keyboard will start the web browser.
+The compositor does not have a menu bar, and it is recommended the user set up, at minimal, a terminal emulator before migration.
+The manual page contains a great deal of documentation it should be read before performing a full migration.
+Another positive aspect about Hikari is that, while migrating to the compositor, Hikari can be started in the Plasma and GNOME desktop environments, allowing for a test-drive before completely migrating.
+
+Locking the screen in Hikari is easy because a default [.filename]#pam.d# configuration file and unlock utility are bundled with the package.
+The key binding for locking the screen is kbd:[L] (Windows logo key)+ kbd:[Shift] + kbd:[Backspace].
+It should be noted that all views not marked public will be hidden.
+These views will never accept input when locked but beware of sensitive information being visible.
+For some users, it may be easier to migrate to a different screen locking utility such as swaylock-effects, discussed in this section.
+To start Hikari, use the following command:
+
+[source,shell]
+----
+% hikari -c ~/.config/hikari/hikari.conf
+----
+
+=== The Sway Compositor
+
+The Sway compositor is a tiling compositor that attempts to replace the i3 windows manager.
+It should work with the user's current i3 configuration; however, new features may require some additional setup.
+In the forthcoming examples, a fresh installation without migrating any i3 configuration will be assumed.
+To install Sway and valuable components, issue the following command as the root user:
+
+[source,shell]
+----
+# pkg install sway swayidle swaylock-effects alacritty dmenu-wayland dmenu
+----
+
+For a basic configuration file, issue the following commands and then edit the configuration file after it is copied:
+
+[source,shell]
+----
+% mkdir ~/.config/sway
+% cp /usr/local/etc/sway/config ~/.config/sway
+----
+
+The base configuration file has many defaults, which will be fine for most users.
+Several important changes should be made like the following:
+
+[.programlisting]
+....
+# Logo key. Use Mod1 for Alt.
+input * xkb_rules evdev
+set $mod Mod4
+# Your preferred terminal emulator
+set $term alacritty
+set $lock swaylock -f -c 000000
+output "My Workstation" mode 1366x786@60Hz position 1366 0
+output * bg ~/wallpapers/mywallpaper.png stretch
+### Idle configuration
+exec swayidle -w \
+ timeout 300 'swaylock -f -c 000000' \
+ timeout 600 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"' \
+ before-sleep 'swaylock -f -c 000000'
+....
+
+In the previous example, the `xkb` rules for man:evdev[4] events are loaded, and the $mod key is set to the Windows logo key for the key bindings.
+Next, the terminal emulator was set to be `alacritty`, and a screen lock command was defined; more on this later.
+The output keyword, the mode, the position, a background wallpaper, and Sway is also told to stretch this wallpaper to fill out the screen.
+Finally, `swaylock` is set to daemonize and lock the screen after a timeout of 300 seconds, placing the screen or monitor into sleep mode after 600 seconds.
+The locked background color of 000000, which is black, is also defined here.
+Using swaylock-effects, a clock may also be displayed with the `--clock` parameter.
+See the manual page for more options.
+The man:sway-output[5] manual page should also be reviewed; it includes a great deal of information on customing the output options available.
+
+While in Sway, to bring up a menu of applications, hold the Windows logo key (mod) and press the kbd:[d] key.
+The menu may be navigated using the arrow keys on the keyboard.
+There is also a method to manipulate the layout of the bar and add a tray; read the man:sway-bar[5] manual page for more information.
+The default configuration adds a date and time to the upper right-hand corner.
+See the `Bar` stanza in the configuration file for an example.
+By default, the configuration does not include locking the screen outside of the example above, enabling a lockout timer.
+Creating a lock key binding requires the following line to the `Key bindings` section:
+
+[.programlising]
+....
+# Lock the screen manually
+bindsym $mod+Shift+Return exec $lock
+....
+
+Now the screen may be locked using the combination of holding the Windows logo key, pressing and holding shift, and finally pressing return.
+When Sway is installed, whether from a package or the FreeBSD Ports Collection, a default file for [.filename]#pam.d# was installed.
+The default configuration should be acceptable for most users, but more advanced options are available.
+Read through the PAM documentation for more information.
+
+Finally, to exit Sway and return to the shell, hold the Windows logo key, the shift key, and press the kbd:[e] key.
+A prompt will be displayed with an option to exit Sway.
+During migration, Sway can be started through a terminal emulator on an X11 desktop such as Plasma.
+This makes testing different changes and key bindings a little easier prior to fully migrating to this compositor.
+To start Sway, issue the following command:
+
+[source,shell]
+----
+% sway -c ~/.config/sway/config
+----
+
+=== Using Xwayland
+
+When installing Wayland, the `Xwayland` binary should have been installed unless Wayland was built without X11 support.
+If the [.filename]#/usr/local/bin/Xwayland# file does not exist, install it using the following command:
+
+[source,shell]
+----
+# pkg install xwayland-devel
+----
+
+[NOTE]
+====
+The development version of Xwayland is recommended and was most likely installed with the Wayland package.
+Each compositor has a method of enabling or disabling this feature.
+====
+
+Once `Xwayland` has been installed, configure it within the chosen compositor.
+For Wayfire, the following line is required in the [.filename]#wayfire.ini# file:
+
+[.programlisting]
+....
+xwayland = true
+....
+
+For the Sway compositor, `Xwayland` should be enabled by default.
+Even so, it is recommened to manually add a configuration line in the [.filename]#~/.config/sway/config# like the following:
+
+[.programlisting]
+.....
+xwayland enable
+.....
+
+Finally, for Hikari, no changes are needed.
+Support for `Xwayland` is build in by default.
+To disable that support, rebuild the package from the ports collection and disable Xwayland support at that time.
+
+After these changes are made, start the compositor at the command line and execute a terminal from the key bindings.
+Within this terminal, issue the `env` command and search for the `DISPLAY` variables.
+If the compositor was able to properly start the Xwayland X server, these environment variables should look similar to the following:
+
+[source,shell]
+----
+% env | grep DISPLAY
+----
+
+[.programlisting]
+....
+WAYLAND_DISPLAY=wayland-1
+DISPLAY=:0
+....
+
+In this output, there is a default Wayland display and a display set for the Xwayland server.
+Another method to verify that `Xwayland` is functioning properly is to use install and test the small package:[x11/eyes] and check the output.
+If the `xeyes` application starts and the eyes follow the mouse pointer, Xwayland is functioning properly.
+If an error such as the following is displayed, something happened during the `Xwayland` intitialization and it may need reinstalled:
+
+[.programlisting]
+....
+Error: Cannot open display wayland-0
+....
+
+[WARNING]
+====
+A security feature of Wayland is that, without running an X server, there is not another network listener.
+Once `Xwayland` is enabled, this security feature is no longer applicable to the system.
+====
+
+For some compositors, such as Wayfire, `Xwayland` may not start properly.
+As such, `env` will show the following information for the `DISPLAY` environment variables:
+
+[source,shell]
+----
+% env | grep DISPLAY
+----
+
+[.programlisting]
+....
+DISPLAY=wayland-1
+WAYLAND_DISPLAY=wayland-1
+....
+
+Even though `Xwayfire` was installed and configured, X11 applications will not start giving a display issue.
+To work around this, verify that there is already an instance of `Xwayland` using a UNIX socket through these two methods.
+First, check the output from `sockstat` and search for X11-unix:
+
+[source,shell]
+----
+% sockstat | grep x11
+----
+
+There should be something similar to the following information:
+
+[.programlisting]
+....
+trhodes Xwayland 2734 8 stream /tmp/.X11-unix/X0
+trhodes Xwayland 2734 9 stream /tmp/.X11-unix/X0
+trhodes Xwayland 2734 10 stream /tmp/.X11-unix/X0
+trhodes Xwayland 2734 27 stream /tmp/.X11-unix/X0_
+trhodes Xwayland 2734 28 stream /tmp/.X11-unix/X0
+....
+
+This suggests the existence of an X11 socket.
+This can be further verified by attempting to execute `Xwayland` manually within a terminal emulator running under the compositor:
+
+[source,shell]
+----
+% Xwayland
+----
+
+If an X11 socket is already available, the following error should be presented to the user:
+
+[.programlisting]
+....
+(EE)
+Fatal server error:
+(EE) Server is already active for display 0
+ If this server is no longer running, remove /tmp/.X0-lock
+ and start again.
+(EE)
+....
+
+Since there is an active X display available using display zero, the environment variable was just set improperly, to fix this, change the `DISPLAY` environment variable to `:0` and attempt to execute the application again.
+The following example uses package:mail/claws-mail[] as the application which needs the `Xwayland` service:
+
+[source,shell]
+----
+export DISPLAY=:0
+----
+
+After this change, the package:mail/claws-mail[] application should now start using `Xwayland` and function as expected.
+
+=== Remote Desktop Using VNC
+
+Earlier in this document it was noted that Wayland does not provide the same X server style access as Xorg provides.
+Instead, users are free to pick and choose a remote desktop protocol such as RDP or VNC.
+The FreeBSD Ports collection includes the `wayvnc`, which will support wlroots based compositors such as the ones discussed here.
+This application may be installed using:
+
+[source,shell]
+----
+# pkg install wayvnc
+----
+
+Unlike some other packages, `wayvnc` does not come with a configuration file.
+Thankfully, the manual page documents the important options and they may be extrapolated into a simple configuration file:
+
+[.programlisting]
+....
+address=0.0.0.0
+enable_auth=true
+username=username
+password=password
+private_key_file=/path/to/key.pem
+certificate_file=/path/to/cert.pem
+....
+
+The key files will need to be generated, and it is highly recommended they be used for increased security of the connection.
+When invoked, wayvnc will search for the configuration file in [.filename]#~/.config/wayvnc/config#.
+This could be overwritten using the `-C configuration_file` option when starting the server.
+Thus, to start the `wayvnc` server, issue the following command:
+
+[source,shell]
+----
+% wayvnc -C ~/.config/wayvnc/config
+----
+
+[NOTE]
+====
+At the time of this writing, there is no rc.d script to start `wayvnc` on system initialization.
+If that functionality is desired, a local startup file will need to be created.
+This is probably a feature request for the port maintainer.
+====
+
+=== Wayland Login Manager
+While several login managers exist and are slowly migrating to Wayland, one option is the package:x11/ly[] text user interface (TUI) manager.
+Needing minimal configuration, `ly` will start Sway, Wayfire, and others by presenting a login window on system initialization.
+To install `ly`, issue the following command:
+
+[source,shell]
+----
+# pkg install ly
+----
+
+There will be some configuration hints presented, the import steps are to add the following lines to [.filename]#/etc/gettytab#:
+
+[programlisting]
+....
+Ly:\
+ :lo=/usr/local/bin/ly:\
+ :al=root:
+....
+
+And then modify the ttyv1 line in [.filename]#/etc/ttys# to match the following line:
+
+[programlisting]
+....
+ttyv1 "/usr/libexec/getty Ly" xterm onifexists secure
+....
+
+After a system reboot, a login should appear.
+To configure specific settings, such as language and edit [.filename]#/usr/local/etc/ly/config.ini#.
+At minimal, this file should have the designated tty that was previously specified in [.filename]#/etc/ttys#.
+
+[NOTE]
+====
+If setting ttyv0 up as the login terminal, it may be required to press the kbd:[alt] and kbd:[F1] keys to properly see the login window.
+====
+
+When the login window appears, using the left and right arrows will swap through different, supported, window managers.
+
+
+=== Useful Utilities
+
+One useful Wayland utility which all compositors can make use of is the waybar.
+While Wayfire does come with a launch menu, an easy-to-use and fast taskbar is a good accessory for any compositor or desktop manager.
+A Wayland compatible taskbar that is fast and easy to configure is waybar.
+To install the package and a supporting audio control utility, issue the following command:
+
+[source,shell]
+----
+# pkg install pavucontrol waybar
+----
+
+To create the configuration directory and copy over a default configuration file, execute the following commands:
+
+[source,shell]
+----
+% mkdir ~/.config/waybar
+% cp /usr/local/etc/xdg/waybar/config ~/.config/waybar
+----
+
+The `lavalauncher` utility provides a launch bar for various applications.
+There is no example configuration file provided with the package, so the following actions must be taken:
+
+[source,shell]
+----
+mkdir ~/.config/lavalauncher
+----
+
+An example configuration file that only includes Firefox, and is placed on the right, is below:
+
+[.programlising]
+....
+global-settings {
+ watch-config-file = true;
+}
+
+bar {
+ output = eDP-1;
+ position = bottom;
+ background-colour = "#202020";
+
+ # Condition for the default configuration set.
+ condition-resolution = wider-than-high;
+
+ config {
+ position = right;
+ }
+
+ button {
+ image-path = /usr/local/lib/firefox/browser/chrome/icons/default/default48.png;
+ command[mouse-left] = /usr/local/bin/firefox;
+ }
+ button {
+ image-path = /usr/local/share/pixmaps/thunderbird.png;
+ command[mouse-left] = /usr/local/bin/thunderbird;
+}
+....
diff --git a/documentation/content/en/books/handbook/zfs/_index.adoc b/documentation/content/en/books/handbook/zfs/_index.adoc
index 3f9a2a457d..3fa7e2fb13 100644
--- a/documentation/content/en/books/handbook/zfs/_index.adoc
+++ b/documentation/content/en/books/handbook/zfs/_index.adoc
@@ -2245,7 +2245,7 @@ Sending the differences alone took much less time to transfer and saved disk spa
This is useful when replicating over a slow network or one charging per transferred byte.
A new file system, _backup/mypool_, is available with the files and data from the pool _mypool_.
-Specifying `-P` copies the dataset properties including compression settings, quotas, and mount points.
+Specifying `-p` copies the dataset properties including compression settings, quotas, and mount points.
Specifying `-R` copies all child datasets of the dataset along with their properties.
Automate sending and receiving to create regular backups on the second pool.
@@ -2692,9 +2692,8 @@ For a more detailed list of recommendations for ZFS-related tuning, see https://
[[zfs-links]]
== Further Resources
-* http://open-zfs.org[OpenZFS]
+* https://openzfs.org/[OpenZFS]
* https://wiki.freebsd.org/ZFSTuningGuide[FreeBSD Wiki - ZFS Tuning]
-* http://docs.oracle.com/cd/E19253-01/819-5461/index.html[Oracle Solaris ZFS Administration Guide]
* https://calomel.org/zfs_raid_speed_capacity.html[Calomel Blog - ZFS Raidz Performance, Capacity and Integrity]
[[zfs-term]]
@@ -2725,7 +2724,7 @@ a|A pool consists of one or more vdevs, which themselves are a single disk or a
====
Using an entire disk as part of a bootable pool is strongly discouraged, as this may render the pool unbootable.
Likewise, you should not use an entire disk as part of a mirror or RAID-Z vdev.
-Reliably determining the size of an unpartitioned disk at boot time is impossible and because there's no place to put in boot code.
+Reliably determining the size of an unpartitioned disk at boot time is impossible and there's no place to put in boot code.
====
* [[zfs-term-vdev-file]] _File_ - Regular files may make up ZFS pools, which is useful for testing and experimentation. Use the full path to the file as the device path in `zpool create`.
diff --git a/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc b/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc
index 2a8cf3e639..9061a38d2b 100644
--- a/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/keeping-up/_index.adoc
@@ -110,23 +110,3 @@ A search function on this page allows the user to search for a specific port.
Clicking on a port name in the list displays the http://freshports.org[FreshPorts] port information.
Additional documentation is available in the https://github.com/freebsd/portscout[Portscout repository].
-
-[[portsmon]]
-== The FreeBSD Ports Monitoring System
-
-Another handy resource is the http://portsmon.FreeBSD.org[FreeBSD Ports Monitoring System] (also known as `portsmon`).
-This system comprises a database that processes information from several sources and allows it to be browsed via a web interface.
-Currently, the ports Problem Reports (PRs), the error logs from the build cluster, and individual files from the ports collection are used.
-In the future, this will be expanded to include the distfile survey, as well as other sources.
-
-To get started, use the http://portsmon.FreeBSD.org/portoverview.py[Overview of One Port] search page to find all the information about a port.
-
-This is the only resource available that maps PR entries to portnames.
-PR submitters do not always include the portname in their Synopsis, although we would prefer that they did.
-So, `portsmon` is a good place to find out whether an existing port has any PRs filed against it, any build errors,
-or if a new port the porter is considering creating has already been submitted.
-
-[NOTE]
-======
-The FreeBSD Ports Monitoring System (portsmon) is currently not working due to latest Python updates.
-======
diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
index 5d2f4cd1b7..10a76f01da 100644
--- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
@@ -306,6 +306,7 @@ Examples of changes which do not require a `PORTREVISION` bump:
* Changes to `MASTER_SITES` or other functional changes to the port which do not affect the resulting package.
* Trivial patches to the distfile such as correction of typos, which are not important enough that users of the package have to go to the trouble of upgrading.
* Build fixes which cause a package to become compilable where it was previously failing. As long as the changes do not introduce any functional change on any other platforms on which the port did previously build. Since `PORTREVISION` reflects the content of the package, if the package was not previously buildable then there is no need to increase `PORTREVISION` to mark a change.
+* Changes to `MAINTAINER`.
A rule of thumb is to decide whether a change committed to a port is something which _some_ people would benefit from having.
Either because of an enhancement, fix, or by virtue that the new package will actually work at all.
@@ -4998,6 +4999,22 @@ Build conflicts are not recorded in the resulting package.
If the port cannot be built if a certain port is already installed and the resulting package cannot coexist with the other package.
`CONFLICTS` check is done prior to the build stage and prior to the install stage.
+Each space-separated item in the `CONFLICTS*` variable values is matched against packages except the one being built, using shell globbing rules.
+This allows listing all flavors of a port in a conflict list instead of having to take pains to exclude the flavor being built from that list.
+For example, if git-lite is installed, `CONFLICTS_INSTALL=git git-lite` would allow to perform:
+[source,shell]
+....
+% make -C devel/git FLAVOR=lite all deinstall install
+....
+
+But the following command would report a conflict, since the package base name installed is `git-lite`, while `git` would be built, but cannot be installed in addition to `git-lite`:
+[source,shell]
+....
+% make -C devel/git FLAVOR=default all deinstall install
+....
+
+Without that feature, the Makefile would need one `_flavor__CONFLICTS_INSTALL` for each flavor, listing every other flavor.
+
The most common content of one of these variable is the package base of another port.
The package base is the package name without the appended version, it can be obtained by running `make -V PKGBASE`.
@@ -5209,11 +5226,11 @@ These targets are described in <<options-targets>>.
Here are some handy variables and how they are expanded by default when used in the [.filename]#Makefile#:
-* `DATADIR` gets expanded to [.filename]#PREFIX/shared/PORTNAME#.
+* `DATADIR` gets expanded to [.filename]#PREFIX/share/PORTNAME#.
* `DATADIR_REL` gets expanded to [.filename]#share/PORTNAME#.
-* `DOCSDIR` gets expanded to [.filename]#PREFIX/shared/doc/PORTNAME#.
+* `DOCSDIR` gets expanded to [.filename]#PREFIX/share/doc/PORTNAME#.
* `DOCSDIR_REL` gets expanded to [.filename]#share/doc/PORTNAME#.
-* `EXAMPLESDIR` gets expanded to [.filename]#PREFIX/shared/examples/PORTNAME#.
+* `EXAMPLESDIR` gets expanded to [.filename]#PREFIX/share/examples/PORTNAME#.
* `EXAMPLESDIR_REL` gets expanded to [.filename]#share/examples/PORTNAME#.
[NOTE]
diff --git a/documentation/content/en/books/porters-handbook/order/_index.adoc b/documentation/content/en/books/porters-handbook/order/_index.adoc
index 4c362669cf..057119bed6 100644
--- a/documentation/content/en/books/porters-handbook/order/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/order/_index.adoc
@@ -161,12 +161,12 @@ If the port is marked BROKEN when some conditions are met, and such conditions c
This block is optional. The variables are:
-* crossref:makefiles:[makefile-fetch_depends,`FETCH_DEPENDS`]
-* crossref:makefiles:[makefile-extract_depends,`EXTRACT_DEPENDS`]
-* crossref:makefiles:[makefile-patch_depends,`PATCH_DEPENDS`]
-* crossref:makefiles:[makefile-build_depends,`BUILD_DEPENDS`]
-* crossref:makefiles:[makefile-lib_depends,`LIB_DEPENDS`]
-* crossref:makefiles:[makefile-run_depends,`RUN_DEPENDS`]
+* crossref:makefiles[makefile-fetch_depends,`FETCH_DEPENDS`]
+* crossref:makefiles[makefile-extract_depends,`EXTRACT_DEPENDS`]
+* crossref:makefiles[makefile-patch_depends,`PATCH_DEPENDS`]
+* crossref:makefiles[makefile-build_depends,`BUILD_DEPENDS`]
+* crossref:makefiles[makefile-lib_depends,`LIB_DEPENDS`]
+* crossref:makefiles[makefile-run_depends,`RUN_DEPENDS`]
* `TEST_DEPENDS`
[[porting-order-flavors]]
diff --git a/documentation/content/en/books/porters-handbook/plist/_index.adoc b/documentation/content/en/books/porters-handbook/plist/_index.adoc
index 7ee24afc97..aa027f16c7 100644
--- a/documentation/content/en/books/porters-handbook/plist/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/plist/_index.adoc
@@ -344,24 +344,12 @@ _Never_ use directly, add crossref:uses[uses-desktop-file-utils,`USES=desktop-fi
Add a `@dir` entry for the directory passed as an argument, and run `fc-cache -fs` on that directory after installation and deinstallation.
-[[plist-keywords-fcfontsdir]]
-=== `@fcfontsdir` _directory_
-
-Add a `@dir` entry for the directory passed as an argument, and run `fc-cache -fs`, `mkfontscale` and `mkfontdir` on that directory after installation and deinstallation.
-Additionally, on deinstallation, it removes the [.filename]#fonts.scale# and [.filename]#fonts.dir# cache files if they are empty.
-This keyword is equivalent to adding both <<plist-keywords-fc,`@fc` _directory_>> and <<plist-keywords-fontsdir,`@fontsdir` _directory_>>.
-
[[plist-keywords-fontsdir]]
=== `@fontsdir` _directory_
Add a `@dir` entry for the directory passed as an argument, and run `mkfontscale` and `mkfontdir` on that directory after installation and deinstallation.
Additionally, on deinstallation, it removes the [.filename]#fonts.scale# and [.filename]#fonts.dir# cache files if they are empty.
-[[plist-keywords-glib-schemas]]
-=== `@glib-schemas`
-
-Runs `glib-compile-schemas` on installation and deinstallation.
-
[[plist-keywords-info]]
=== `@info` _file_
diff --git a/documentation/content/en/books/porters-handbook/porting-dads/_index.adoc b/documentation/content/en/books/porters-handbook/porting-dads/_index.adoc
index 9693c0ca93..36b9691d31 100644
--- a/documentation/content/en/books/porters-handbook/porting-dads/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/porting-dads/_index.adoc
@@ -315,7 +315,7 @@ In certain cases, users must be prevented from installing a port.
There are several variables that can be used in a port's [.filename]#Makefile# to tell the user that the port cannot be installed.
The value of these make variables will be the reason that is shown to users for why the port refuses to install itself.
Please use the correct make variable.
-Each variable conveys radically different meanings, both to users and to automated systems that depend on [.filename]##Makefile##s, such as crossref:keeping-up[build-cluster,the ports build cluster], crossref:keeping-up[freshports,FreshPorts], and crossref:keeping-up[portsmon,portsmon].
+Each variable conveys radically different meanings, both to users and to automated systems that depend on [.filename]##Makefile##s, such as crossref:keeping-up[build-cluster,the ports build cluster], and crossref:keeping-up[freshports,FreshPorts].
[[dads-noinstall-variables]]
=== Variables
@@ -547,6 +547,4 @@ For example, [.filename]#sys/types.h# is often forgotten, which is not as much o
Always double-check [.filename]#pkg-descr# and [.filename]#pkg-plist#.
If reviewing a port and a better wording can be achieved, do so.
-Do not copy more copies of the GNU General Public License into our system, please.
-
Please be careful to note any legal issues! Do not let us illegally distribute software!
diff --git a/documentation/content/en/books/porters-handbook/special/_index.adoc b/documentation/content/en/books/porters-handbook/special/_index.adoc
index a7ad7f9aad..7bef554080 100644
--- a/documentation/content/en/books/porters-handbook/special/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/special/_index.adoc
@@ -2141,7 +2141,7 @@ The most commonly used components are listed below (all available components are
|Qt functions to access serial ports
|`speech`
-|Accessibilty features for Qt5
+|Accessibility features for Qt5
|`sql`
|Qt SQL database integration module
@@ -2991,7 +2991,7 @@ If the port needs a Java(TM) Development Kit (JDK(TM)) to either build, run or e
There are several JDKs in the ports collection, from various vendors, and in several versions.
If the port must use a particular version, specify it using the `JAVA_VERSION` variable.
-The most current version is package:java/openjdk16[], with package:java/openjdk15[], package:java/openjdk14[], package:java/openjdk13[], package:java/openjdk12[], package:java/openjdk11[], package:java/openjdk8[], and package:java/openjdk7[] also available.
+The most current version is package:java/openjdk18[], with package:java/openjdk17[], package:java/openjdk16[], package:java/openjdk15[], package:java/openjdk14[], package:java/openjdk13[], package:java/openjdk12[], package:java/openjdk11[], package:java/openjdk8[], and package:java/openjdk7[] also available.
[[using-java-variables]]
.Variables Which May be Set by Ports That Use Java
@@ -3004,7 +3004,7 @@ The most current version is package:java/openjdk16[], with package:java/openjdk1
|Define for the remaining variables to have any effect.
|`JAVA_VERSION`
-|List of space-separated suitable Java versions for the port. An optional `"+"` allows specifying a range of versions (allowed values: `7[+] 8[+] 11[+] 12[+] 13[+] 14[+] 15[+] 16[+]`).
+|List of space-separated suitable Java versions for the port. An optional `"+"` allows specifying a range of versions (allowed values: `7[+] 8[+] 11[+] 12[+] 13[+] 14[+] 15[+] 16[+] 17[+] 18[+]`).
|`JAVA_OS`
|List of space-separated suitable JDK port operating systems for the port (allowed values: `native linux`).
diff --git a/documentation/content/en/books/porters-handbook/upgrading/_index.adoc b/documentation/content/en/books/porters-handbook/upgrading/_index.adoc
index 3cd5e01f68..14ddf24af6 100644
--- a/documentation/content/en/books/porters-handbook/upgrading/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/upgrading/_index.adoc
@@ -59,16 +59,6 @@ To do this, there are two options.
There is a searchable interface to the https://bugs.freebsd.org/search/[FreeBSD Problem Report (PR) or bug database].
Select `Ports & Packages` in the `Product` multiple select menu, and enter the name of the port in the `Summary` field.
-However, sometimes people forget to put the name of the port into the Summary field in an unambiguous fashion.
-In that case, try searching in the `Comment` field in the `Detailled Bug Information` section, or try the crossref:keeping-up[portsmon,FreeBSD Ports Monitoring System] (also known as `portsmon`).
-This system attempts to classify port PRs by portname.
-To search for PRs about a particular port, use the http://portsmon.FreeBSD.org/portoverview.py[Overview of One Port].
-
-[NOTE]
-======
-The FreeBSD Ports Monitoring System (portsmon) is currently not working due to latest Python updates.
-======
-
If there is no pending PR, the next step is to send an email to the port's maintainer, as shown by `make maintainer`.
That person may already be working on an upgrade, or have a reason to not upgrade the port right now (because of, for example, stability problems of the new version), and there is no need to duplicate their work.
Note that unmaintained ports are listed with a maintainer of `ports@FreeBSD.org`, which is just the general ports mailing list, so sending mail there probably will not help in this case.
diff --git a/documentation/content/en/books/porters-handbook/uses/_index.adoc b/documentation/content/en/books/porters-handbook/uses/_index.adoc
index e7e74d9f25..959bbb2c7f 100644
--- a/documentation/content/en/books/porters-handbook/uses/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/uses/_index.adoc
@@ -373,6 +373,29 @@ Possible arguments: 2, 3, build (default), run
Add dependency on package:math/eigen[].
+[[uses-elfctl]]
+== `elfctl`
+
+Possible arguments: (none)
+
+Change an ELF binary's feature control note by setting ELF_FEATURES.
+
+[[uses-elfct-ex1]]
+.Uses=elfctl
+[example]
+====
+[.programlisting]
+....
+USES= elfctl
+ELF_FEATURES= featurelist:path/to/file1 \
+ featurelist:path/to/file1 \
+ featurelist:path/to/file2
+....
+
+====
+
+The format of `featurelist` is described in man:elfctl[1]. The file paths are relative to ${BUILD_WRKSRC}.
+
[[uses-fakeroot]]
== `fakeroot`
@@ -399,10 +422,10 @@ Add a dependency to the client library of the Firebird database.
[[uses-fonts]]
== `fonts`
-Possible arguments: (none), `fc`, `fcfontsdir` (default), `fontsdir`, `none`
+Possible arguments: (none), `fc`, `fontsdir` (default), `none`
Adds a runtime dependency on tools needed to register fonts.
-Depending on the argument, add a `crossref:plist[plist-keywords-fc,@fc] ${FONTSDIR}` line, `crossref:plist[plist-keywords-fcfontsdir,@fcfontsdir] ${FONTSDIR}` line, `crossref:plist[plist-keywords-fontsdir,@fontsdir] ${FONTSDIR}` line, or no line if the argument is `none`, to the plist.
+Depending on the argument, add a `crossref:plist[plist-keywords-fc,@fc] ${FONTSDIR}` line, `crossref:plist[plist-keywords-fontsdir,@fontsdir] ${FONTSDIR}` line, or no line if the argument is `none`, to the plist.
`FONTSDIR` defaults to [.filename]#${PREFIX}/share/fonts/${FONTNAME}# and `FONTNAME` to `${PORTNAME}`.
Add `FONTSDIR` to `PLIST_SUB` and `SUB_LIST`
@@ -614,14 +637,14 @@ See crossref:special[using-gnome,Using GNOME] for more information.
Ports should not be created for Go libs, see crossref:special[go-libs,Go Libraries] for more information.
====
-Possible arguments: (none), `modules`, `no_targets`, `run`
+Possible arguments: (none), `N.NN`, `N.NN-devel`, `modules`, `no_targets`, `run`
Sets default values and targets used to build Go software.
-A build dependency on the Go compiler port selected via `GO_PORT` is added.
+A build dependency on the Go compiler port is added, port maintainers can set version required.
By default the build is performed in GOPATH mode.
If Go software uses modules, the modules-aware mode can be switched on with `modules` argument.
-`no_targets` will setup build environment like `GO_ENV`, `GO_BUILDFLAGS` but skip creating `post-extract` and `do-{build,install,test}` targets.
-`run` will also add a run dependency on what is in `GO_PORT`.
+`no_targets` will setup build environment like `GO_ENV`, `GO_BUILDFLAGS` but skip creating extract and build targets.
+`run` will also add a run dependency on the Go compiler port.
The build process is controlled by several variables:
@@ -656,15 +679,6 @@ Additional build arguments to be passed to `go build`.
`GO_TESTFLAGS`::
Additional build arguments to be passed to `go test`.
-`GO_PORT`::
-The Go compiler port to use.
-By default this is package:lang/go[] but can be set to package:lang/go-devel[] in `make.conf` for testing with future Go versions.
-+
-[WARNING]
-====
-This variable must not be set by individual ports!
-====
-
See crossref:special[using-go,Building Go Applications] for usage examples.
[[uses-gperf]]
@@ -738,6 +752,111 @@ GSSAPI_NONE_CONFIGURE_ON= --without-gssapi
====
+[[uses-gstreamer]]
+== `gstreamer`
+
+Possible arguments: (none)
+
+Provides an easy way to depend on GStreamer components.
+The components should be listed in `USE_GSTREAMER`.
+The available components are:
+
+* `a52dec`
+* `aalib`
+* `amrnb`
+* `amrwbdec`
+* `aom`
+* `assrender`
+* `bad`
+* `bs2b`
+* `cairo`
+* `cdio`
+* `cdparanoia`
+* `chromaprint`
+* `curl`
+* `dash`
+* `dtls`
+* `dts`
+* `dv`
+* `dvd`
+* `dvdread`
+* `editing-services`
+* `faac`
+* `faad`
+* `flac`
+* `flite`
+* `gdkpixbuf`
+* `gl`
+* `gme`
+* `gnonlin`
+* `good`
+* `gsm`
+* `gtk4`
+* `gtk`
+* `hal`
+* `hls`
+* `jack`
+* `jpeg`
+* `kate`
+* `kms`
+* `ladspa`
+* `lame`
+* `libav`
+* `libcaca`
+* `libde265`
+* `libmms`
+* `libvisual`
+* `lv2`
+* `mm`
+* `modplug`
+* `mpeg2dec`
+* `mpeg2enc`
+* `mpg123`
+* `mplex`
+* `musepack`
+* `neon`
+* `ogg`
+* `opencv`
+* `openexr`
+* `openh264`
+* `openjpeg`
+* `openmpt`
+* `opus`
+* `pango`
+* `png`
+* `pulse`
+* `qt`
+* `resindvd`
+* `rsvg`
+* `rtmp`
+* `shout2`
+* `sidplay`
+* `smoothstreaming`
+* `sndfile`
+* `sndio`
+* `soundtouch`
+* `soup`
+* `spandsp`
+* `speex`
+* `srtp`
+* `taglib`
+* `theora`
+* `ttml`
+* `twolame`
+* `ugly`
+* `v4l2`
+* `vorbis`
+* `vpx`
+* `vulkan`
+* `wavpack`
+* `webp`
+* `webrtcdsp`
+* `x264`
+* `x265`
+* `x`
+* `ximagesrc`
+* `zbar`
+
[[uses-horde]]
== `horde`
@@ -1017,6 +1136,13 @@ Possible arguments: (none)
Sets the following variables to make it easier to create a metaport: `MASTER_SITES`, `DISTFILES`, `EXTRACT_ONLY`, `NO_BUILD`, `NO_INSTALL`, `NO_MTREE`, `NO_ARCH`.
+[[uses-minizip]]
+== `minizip`
+
+Possible arguments: (none), `ng`
+
+Adds a library dependency on package:archivers/minizip[] or package:archivers/minizip-ng[] respectively.
+
[[uses-mysql]]
== `mysql`
@@ -1068,6 +1194,15 @@ Possible arguments: (none)
Uses ninja to build the port.
+[[uses-nodejs]]
+== `nodejs`
+
+Possible arguments: (none), `build`, `run`, `current`, `lts`, `10`, `14`, `16`,
+ `17`.
+
+Uses nodejs. Adds a dependency on package:www/node*[]. If a supported version is
+specified then `run` and/or `build` must be specified too.
+
[[uses-objc]]
== `objc`
@@ -1328,6 +1463,42 @@ USES= pyqt
USE_PYQT= core doc_build designer_run
....
+[[uses-pytest]]
+== `pytest`
+
+Possible arguments: (none), 4
+
+Introduces a new dependency on package:devel/pytest[]. It defines a `do-test`
+target which will run the tests properly.
+Use the argument to depend on a specific package:devel/pytest[] version.
+For ports using package:devel/pytest[] consider using this instead of a specific
+`do-test` target.
+The framework exposes the following variables to the port:
+
+`PYTEST_ARGS`::
+Additional arguments to pytest (defaults to empty).
+
+`PYTEST_IGNORED_TESTS`::
+lists of `pytest -k` patterns of tests to ignore (defaults to empty). For tests
+which are not expected to pass, such as ones requiring a database access.
+
+`PYTEST_BROKEN_TESTS`::
+lists of `pytest -k` patterns of tests to ignore (defaults to empty). For broken
+tests which require fixing.
+
+In addition the following variables may be set by the user:
+
+`PYTEST_ENABLE_IGNORED_TESTS`::
+Enable tests which are otherwise ignored by `PYTEST_IGNORED_TESTS`.
+
+`PYTEST_ENABLE_BROKEN_TESTS`::
+Enable tests which are otherwise ignored by `PYTEST_BROKEN_TESTS`.
+
+`PYTEST_ENABLE_ALL_TESTS`::
+Enable tests which are otherwise ignored by `PYTEST_IGNORED_TESTS` and
+`PYTEST_BROKEN_TESTS`.
+
+
[[uses-python]]
== `python`
@@ -1655,9 +1826,11 @@ BROKEN_SSL_REASON_libressl= needs features only available in OpenSSL
[[uses-tar]]
== `tar`
-Possible arguments: (none), `Z`, `bz2`, `bzip2`, `lzma`, `tbz`, `tbz2`, `tgz`, `txz`, `xz`
+Possible arguments: (none), `Z`, `bz2`, `bzip2`, `lzma`, `tbz`, `tbz2`, `tgz`,
+`txz`, `xz`, `zst`, `zstd`
-Set `EXTRACT_SUFX` to `.tar`, `.tar.Z`, `.tar.bz2`, `.tar.bz2`, `.tar.lzma`, `.tbz`, `.tbz2`, `.tgz`, `.txz` or `.tar.xz` respectively.
+Set `EXTRACT_SUFX` to `.tar`, `.tar.Z`, `.tar.bz2`, `.tar.bz2`, `.tar.lzma`,
+`.tbz`, `.tbz2`, `.tgz`, `.txz`, `.tar.xz`, `.tar.zst` or `.tar.zstd` respectively.
[[uses-tcl]]
== `tcl`
@@ -1721,11 +1894,10 @@ These variables are available for ports:
[[uses-varnish]]
== `varnish`
-Possible arguments: `4`, `6`
+Possible arguments: `4` (default), `6`, `7`
Handle dependencies on Varnish Cache.
-`4` will add a dependency on package:www/varnish4[].
-`6` will add a dependency on package:www/varnish6[].
+Adds a dependency on package:www/varnish*[].
[[uses-webplugin]]
== `webplugin`
diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc
index 0c0f643214..bd9ce57336 100644
--- a/documentation/content/en/books/porters-handbook/versions/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc
@@ -1,7 +1,7 @@
---
title: Chapter 18. __FreeBSD_version Values
prev: books/porters-handbook/uses
-description: A list of changes into the sys/param.h file
+description: A list of changes to the sys/param.h file
tags: ["FreeBSD versions"]
showBookMenu: true
weight: 18
@@ -269,6 +269,86 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg
|gitref:b214fcceacad6b842545150664bd2695c1c2b34f[repository="src",length=12]
|December 15, 2021
|14.0-CURRENT after changing man:VOP_READDIR[9]'s cookies argument to a `**uint64_t`.
+
+|1400046
+|gitref:e2650af157bc7489deaf2c9054995f0f88a6e5da[repository="src",length=12]
+|December 30, 2021
+|14.0-CURRENT after making the CPU_SET macros compatible with glibc.
+
+|1400047
+|gitref:ed6417cd8d0bb5a2c175fce9d8e4a495fae9e9f4[repository="src",length=12]
+|January 17, 2022
+|14.0-CURRENT after multiple LinuxKPI changes required by drm-kmod.
+
+|1400048
+|gitref:dd2f7a4b45eb1285e710cfce60cb77f7c11f8075[repository="src",length=12]
+|January 18, 2022
+|14.0-CURRENT after adding <crypto/chacha20_poly1305.h>.
+
+|1400049
+|gitref:2c4b65cc3d227f31864e183c15f6c42e2c596cd9[repository="src",length=12]
+|January 24, 2022
+|14.0-CURRENT after adding <crypto/curve25519.h>.
+
+|1400050
+|gitref:213e91399b7998554d787bb290109ebe602aa279[repository="src",length=12]
+|January 25, 2022
+|14.0-CURRENT after iflib adds the feature that a driver can set its own TX queue selection function as ift_txq_select in struct if_txrx.
+
+|1400051
+|gitref:59d465e200bb7058dfdb183c061730c10dd5bc03[repository="src",length=12]
+|January 25, 2022
+|14.0-CURRENT after adding i2c support for LinuxKPI.
+
+|1400052
+|gitref:05f0b24bfb3416606c8ea02bc1bdb9bcee7aee0c[repository="src",length=12]
+|February 14, 2022
+|14.0-CURRENT after adding GUID_INIT and pm_qos.h support for LinuxKPI.
+
+|1400053
+|gitref:ba87e9bf74202b08b8e3b0a297b9b88f6869fbfb[repository="src",length=12]
+|February 17, 2022
+|14.0-CURRENT after adding mmap_lock.h to LinuxKPI.
+
+|1400054
+|gitref:50bb3a33d879536e86e8a23365f070ef00b5cb32[repository="src",length=12]
+|March 28, 2022
+|14.0-CURRENT after changing irq_work_queue to return a bool in LinuxKPI to match 5.10 API.
+
+|1400055
+|gitref:d69af4758be912625ec08656ba64eb90a98c9a7f[repository="src",length=12]
+|March 29, 2022
+|14.0-CURRENT after adding for_each_sgtable_dma_sg and for_each_sgtable_dma_page to LinuxKPI
+
+|1400056
+|gitref:ab8ac4c28574a42a2891b2e2341f802949c1fb57[repository="src",length=12]
+|March 31, 2022
+|14.0-CURRENT after zlib upgrade to 1.2.12
+
+|1400057
+|gitref:e68b35e40881a1bd858e1b4b5003123a484fd7cd[repository="src",length=12]
+|April 22, 2022
+|14.0-CURRENT after changing udp_tun_func_t() prototype.
+
+|1400058
+|gitref:2e32d4e41d205d6f14834f87306a77ff77b9c0bd[repository="src",length=12]
+|May 7, 2022
+|14.0-CURRENT after newbus changes to remove devclass arguments.
+
+|1400059
+|gitref:3a9a9c0ca44ec535dcf73fe8462bee458e54814b[repository="src",length=12]
+|May 14, 2022
+|14.0-CURRENT after upgrading llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-14.0.3-0-g1f9140064dfb, a.k.a. 14.0.3 release.
+
+|1400060
+|gitref:85d7875d42913c2cb10a007a1be05b210dc6aab2[repository="src",length=12]
+|June 6, 2022
+|14.0-CURRENT after LinuxKPI dmi_matches() fixes.
+
+|1400061
+|gitref:c4c5981c14d5bd69e9df9ae691069ec4c2e92174[repository="src",length=12]
+|June 8, 2022
+|14.0-CURRENT after mbuf(9) structure changes.
|===
////
@@ -1116,6 +1196,51 @@ Template:
|gitref:690bcf605d84283c1f9d254885a3cac69c5e80a6[repository="src",length=12]
|December 18, 2021
|13.0-STABLE after adding two arguments to man:VOP_ALLOCATE[9].
+
+|1300524
+|gitref:dc4114875ef10618002d3eeb46f09dc42da56b30[repository="src",length=12]
+|January 14, 2022
+|13.0-STABLE after making the CPU_SET macros compatible with glibc.
+
+|1300525
+|gitref:dee0854a009cde7dcdb16ba39754237737022c8a[repository="src",length=12]
+|January 22, 2022
+|13.0-STABLE after multiple LinuxKPI changes required by drm-kmod.
+
+|1300526
+|gitref:c39ff2415cb965b729fd16f9eae91e712313877b[repository="src",length=12]
+|February 20, 2022
+|13.0-STABLE after multiple LinuxKPI changes overlapping but not conflicting with drm-kmod.
+
+|1301000
+|gitref:ad329796bdb29c69bce610ad332d08257d7157ac[repository="src",length=12]
+|March 10, 2022
+|releng/13.1 branched.
+
+|1301500
+|gitref:08523c8c63bbcdcd3f0d36787a544817cb5b8282[repository="src",length=12]
+|March 10, 2022
+|13.1-STABLE after releng/13.1 branched.
+
+|1301501
+|gitref:6663718bb49635deac3f5dc55fa6f0f7cba593ba[repository="src",length=12]
+|March 27, 2022
+|13.1-STABLE after various merges to LinuxKPI and net80211.
+
+|1301502
+|gitref:2278cf4e48e7679b0a60008a83c764fe852174b2[repository="src",length=12]
+|April 27, 2022
+|13.1-STABLE after various merges to LinuxKPI.
+
+|1301503
+|gitref:b2aa64d05bd8b04a1bdb63f2a5f9de39c600b463[repository="src",length=12]
+|May 19, 2022
+|13.1-STABLE after adding alternate DRIVER_MODULE macros without a devclass argument.
+
+|1301504
+|gitref:a13b6fc61908fd6afa460b88f94e4a67be74bb9a[repository="src",length=12]
+|June 4, 2022
+|13.1-STABLE after upgrading llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvmorg-14.0.3-0-g1f9140064dfb, a.k.a. 14.0.3 release.
|===
////
diff --git a/documentation/content/fr/books/handbook/linuxemu/_index.adoc b/documentation/content/fr/books/handbook/linuxemu/_index.adoc
index 9f615ea14f..05710c9660 100644
--- a/documentation/content/fr/books/handbook/linuxemu/_index.adoc
+++ b/documentation/content/fr/books/handbook/linuxemu/_index.adoc
@@ -1,15 +1,17 @@
---
-title: Chapitre 10. Compatibilité binaire avec Linux®
+title: Chapitre 10. Compatibilité binaire avec Linux
part: Partie II. Tâches courantes
prev: books/handbook/printing
next: books/handbook/partiii
+description: FreeBSD offre une compatibilité binaire avec Linux, permettant aux utilisateurs d'installer et exécuter la plupart des binaires Linux sur un système FreeBSD sans avoir à modifier ce binaire
+tags: ["linux", "linuxulator", "émulation", "binaire", "compatibilité"]
showBookMenu: true
weight: 13
path: "/books/handbook/"
---
[[linuxemu]]
-= Compatibilité binaire avec Linux(R)
+= Compatibilité binaire avec Linux
:doctype: book
:toc: macro
:toclevels: 1
@@ -49,99 +51,144 @@ endif::[]
[[linuxemu-synopsis]]
== Synopsis
-FreeBSD fournit une compatibilité binaire avec Linux(R), permettant aux utilisateurs d'installer et d'exécuter la plupart des applications Linux(R) sur un système FreeBSD sans avoir à modifier ces applications. On rapporte également que dans certaines situations, les binaires Linux sont plus performants sous FreeBSD que sous Linux(R),.
+FreeBSD fournit en option une compatibilité binaire avec Linux(R), permettant aux utilisateurs d'installer et d'exécuter desapplications Linux, sans avoir à les modifier, sur un système FreeBSD.
+Cette option est disponible pour les architectures i386, amd64, et arm64.
-Il existe cependant certaines caractéristiques spécifiques à Linux(R), qui ne sont pas supportées sous FreeBSD. Par exemple, des binaires Linux(R) ne fonctionneront pas sous FreeBSD s'ils utilisent massivement des appels i386(TM) spécifiques, comme activation du mode virtuel 8086.
-[NOTE]
-====
-Le support de la compatibilité Linux(R) pour les binaires 64bits a été ajouté avec FreeBSD 10.3.
-====
+Certaines caractéristiques spécifiques au système Linux ne sont pas encore supportées sous FreeBSD; cela concerne principalement des fonctionnalités spécifiques au matériel ou relatives à la gestion du système, comme les cgroups ou les espaces de noms.
Après la lecture de ce chapitre, vous connaîtrez:
-* Comment activer la compatibilité binaire avec Linux(R) sur un système FreeBSD.
-* Comment installer des bibliothèques partagées Linux(R) supplémentaires.
-* Comment installer des application Linux(R) sur un système FreeBSD.
-* Les détails de l'implémentation de la compatibilité Linux(R) sous FreeBSD.
+* Comment activer la compatibilité binaire avec Linux sur un système FreeBSD.
+* Comment installer des bibliothèques partagées Linux supplémentaires.
+* Comment installer des applications Linux sur un système FreeBSD.
+* Les détails de l'implémentation de la compatibilité Linux sous FreeBSD.
Avant de lire ce chapitre, vous devrez:
* Savoir comment installer des crossref:ports[ports,logiciels tiers].
[[linuxemu-lbc-install]]
-== Configurer la compatibilité binaire avec Linux(R)
+== Configurer la compatibilité binaire avec Linux
-Par défaut, les bibliothèques Linux(R) ne sont pas installées et la compatibilité binaire avec Linux n'est pas activée. Les bibliothèques Linux(R) peuvent être installées soit manuellement soit à partir du catalogue des logiciels portés.
+Par défaut, la compatibilité binaire avec Linux n'est pas activée.
+Pour l'activer au démarrage, ajoutez cette ligne au fichier [.filename]#/etc/rc.conf#:
-Avant de tenter de compiler un logiciel, charger le module du noyau Linux(R), sinon la compilation risque d'échouer:
+[.programlisting]
+....
+linux_enable="YES"
+....
+Une fois activée, elle peut être lancée sans redémarrer en exécutant:
[source,shell]
....
-# kldload linux
+# service linux start
....
-Pour une compatibilité en 64bits:
+La procédure [.filename]#/etc/rc.d/linux# changera les modules noyau nécessaires et montera sous [.filename]#/compat/linux# les systèmes de fichiers attendus par les applications Linux.
+Ceci est suffisant pour faire fonctionner les binaires Linux statiques.
+Ils peuvent être lancés de la même manière qu'un binaire natif FreeBSD; ils se comportent exactement de la même manière que des processus natifs et peuvent être suivis et debogués avec les méthodes habituelles.
+
+Les binaires Linux liés de manière dynamique (c'est la vaste majorité des cas) demandent à ce que les bibliothèques dynamiques partgées Linux soient installées - ils peuvent être exécutés par le noyau FreeBSD, mais ne peuvent pas utiliser les bibliothèques FreeBSD; c'est semblable au principe des binaires 32bits qui ne peuvent pas utiliser les bibliothèques natives 64bits.
+Il existe plusieurs méthodes pour mettre à disposition ces
+bibliothèques: on peut les copier à partir d'une installation Linux
+existante utilisant la même architecture, les installer à partir des
+paquets binaires FreeBSD, ou les installer en utilisant
+man:deboostrap[8] (à partir de package:sysutils/debootstrap[]), etc.
+
+[[linuxemu-packages]]
+== Système de base CentOS à partir des paquets binaires FreeBSD
+
+[NOTE]
+====
+Cette méthode n'est pas encore applicable sous arm64.
+====
+
+La méthode la plus simple pour installer les bibliotèques Linux est
+d'installer la version pré-compilée ou la version compilée à partir du catalogue des logiciels portés package:emulators/linux_base-c7[], qui placera le système de base dérivé de CentOS 7 dans le répertoire [.filename]#/compat/linux#:
[source,shell]
....
-# kldload linux64
+# pkg install linux_base-c7
....
-Pour vérifier que le module est bien chargé:
-
+FreeBSD fournit les paquets des binaires Linux de certaines applications.
+Par exemple, pour installer Sublime Text 4, avec les bibliothèques Linux
+nécessaires, exécuter la commande suivante:
[source,shell]
....
-% kldstat
- Id Refs Address Size Name
- 1 2 0xc0100000 16bdb8 kernel
- 7 1 0xc24db000 d000 linux.ko
+# pkg install linux-sublime-text4
....
-Le logiciel précompilé package:emulators/linux_base-c7[] ou la version compilée à partir du catalogue des logiciels portés est la méthode la plus simple pour installer l'ensemble des bibliothèques et binaires de base Linux(R) sur un système FreeBSD. Pour installer le logiciel porté:
+[[linuxemu-debootstrap]]
+== Système de base Debian / Ubuntu avec man:debootstrap[8]
+
+Une autre solution pour disposer des bibliothèques partagées Linux est
+l'utilisation de package:sysutils/debootstrap[].
+Cela a pour avantage de disposer d'une distribution complète Debian ou
+Ubuntu. Pour l'utiliser, suivez les instructions données sur le Wiki
+FreeBSD: https://wiki.freebsd.org/LinuxJails[FreeBSD Wiki - Linux Jails].
+
+Après cette installation, utilisez man:chroot[8] dans le répertoire nouvellement créé et installez le logiciel suivant la manière classique sous la distribution Linux installée, par exemple:
[source,shell]
....
-# pkg install emulators/linux_base-c7
+# chroot /compat/ubuntu /bin/bash
+root@hostname:/# apt update
....
-Pour activer au démarrage la compatibilité Linux(R), ajouter ligne suivante au fichier [.filename]#/etc/rc.conf#:
+Il est possible d'utiliser debootstrap dans le répertoire [.filename]#/compat/linux#, mais cela est déconseillé pour éviter les colisions avec les fichiers installés à partir des logiciels portés ou pré-compilés FreeBSD.
+A la place, utilisez un nom de répertoire dérivé du nom ou de la version de la distribution, e.g., [.filename]#/compat/ubuntu#.
+Si l'instance debootstrap est destinée à fournir des bibliothèques partagées Linux sans utiliser explicitement chroot ou les jails, on peut faire pointer le noyau dessus en modifiant le paramètre sysctl `compat.linux.emul_path` et en ajoutant une ligne comme ce qui suit au fichier [.filename]#/etc/sysctl.conf#:
[.programlisting]
....
-linux_enable="YES"
+compat.linux.emul_path="/compat/ubuntu"
....
-Sur les machines 64bits, [.filename]#/etc/rc.d/abi# chargera automatiquement le module pour l'émulation 64bits.
+Ce paramètre sysctl contrôle le mécanisme de traduction du chemin du noyau, consultez man:linux[4] pour plus de détails.
+Veuillez noter que ce changement peut être à l'origine de problèmes pour les applications Linux installées à partir des paquets binaires FreeBSD; une des raisons est que beaucoup de ces applications sont toujours en 32bits, alors qu'Ubuntu semble abandonner le support des bibliothèques 32bits.
+
+[[linuxemu-advanced]]
+== Sujets avancés
+
+La couche de compatibilité Linux est un travail en constante progression.
+Consultez https://wiki.freebsd.org/Linuxulator[FreeBSD Wiki - Linuxulator] pour plus d'informations.
-Depuis qu'à été ajouté le support pour l'exécution des binaires Linux(R) 32 et 64 bits à la couche de compatibilité Linux(R) (sur les hôtes 64 bits de type x86), il n'est plus possible d'ajouter l'émulation en statique dans un noyau personnalisé.
+Tous les paramètres man:sysctl[8] relatifs à Linux peuvent être trouvés dans la page de manuel man:linux[4].
-Pour certaines applications, [.filename]#/compat/linux/proc#,
-[.filename]#/compat/linux/sys#, et [.filename]#/compat/linux/dev/shm#
-pourront nécessiter d'être montés. Ajoutez la ligne suivante au fichier
-[.filename]#/etc/fstab#:
+Certaines applications ont besoin que des systèmes de fichiers spécifiques soient montés.
+Cela est normalement géré par la procédure [.filename]#/etc/rc.d/linux#, mais peut être désactivé en