Be explicit that GPUs need no setup, display servers usually included
Graphics is the one driver a FreeBSD user expects to configure by hand --
install drm-kmod, then kld_list="i915kms" or i915kms_load="YES" -- so
"nothing to configure" is not believable unless graphics is named.
It goes through the same match -> kextd -> load -> bind path as any other
kext, and the CI boot test asserts card0 appears with no kextload, failing
if the device only shows up after a manual one.
Two things follow that are worth telling users:
- Autoload is asynchronous. The matcher hands kextd a request that kextd
services on its own schedule, so a GPU can take a second or two to
appear. Normal, not a fault.
- Display servers usually need no setup either. drm-kmod ships no bochs,
virtio-gpu or vmwgfx, so on FreeBSD a VM has no KMS for its virtual GPU
and X falls back to scfb/VESA with a hand-written xorg.conf. NextBSD
vendors those drivers, so a virtual GPU gets real KMS and a card0 node,
and the display server takes the ordinary modesetting path.
Explain that drivers are not configured anywhere, and how kextd does it
Home's second surprise covered the missing kldload CLI but not the thing a
FreeBSD user reaches for next: loader.conf. There is no if_em_load="YES",
no kld_list, and no rc.conf to put either in.
Hardware-Support gains "How drivers load" with the actual chain: kexts
carry IOKitPersonalities (generated from driver source for the Intel
drivers, so they cannot drift), kextd pushes them into the in-kernel IOKit
catalogue, and each push triggers an active rescan of the live PCI tree
that requests a load for every present, driver-less, claimed device.
The section says why the active scan exists, because it is the difference
between working and silently not working: the earlier design only
re-checked devices a device_nomatch event had queued, which was unreliable
on real chipsets -- a laptop could boot with Ethernet and Wi-Fi present and
neither loaded, while qemu was fine and CI stayed green (nextbsd#267).
Ends with the diagnostic that follows from all this: the question is not
"did I load the module" but "does anything claim this device", which is
pciconf -lv | grep -B3 none plus kextstat.
Updated NextBSD Wiki (markdown)
Hardware-Support: add a Bluetooth section pointing at the design ticket
Says plainly that Bluetooth does not work yet and offers no workaround,
then explains why it is a from-scratch design rather than a port -- Apple's
blued sits behind the closed IOBluetooth framework, so unlike launchd or
configd there is no Darwin source to vendor.
Links nextbsd#412 for the design and phasing, notes that HID lands before
audio, and points readers at Discussions if they have hardware or an
opinion on BLE vs classic.
Remove the static-IP page; that gap is work to do, not a doc to write
The page documented a machine-wide workaround -- unload ipconfigd, then
hand-configure and replay it from a launchd job -- which reads as an
apology for a missing feature rather than guidance a user should follow.
Tracking it as issues on nextbsd-userland instead.
Also drops the paragraph in Command-Reference enumerating what ipconfig
does not implement yet.
Document static IP addressing, including why it is a workaround
There is no supported static-IP path today, and the page says so up front
rather than pretending otherwise. Three findings from the source:
- ipconfig ships two subcommands, getifaddr and ifcount. Apple's has
~25 including set, so `ipconfig set em0 MANUAL ...` does not exist
(ipconfig.c commands[]).
- ipconfigd has no config file, no preferences plist and no
per-interface opt-out.
- Its rule is: every non-loopback interface whose link comes up gets
DHCP, and it admin-ups down interfaces so their link can negotiate
(on_link_event). So a hand-configured address is overwritten at the
next link event -- address, default route and /etc/resolv.conf alike.
The only lever is the ipconfigd launchd job, which is machine-wide. The
page states that cost plainly before the procedure: unloading it kills
DHCP everywhere, wlan0 included.
Procedure is unload ipconfigd -> ifconfig + route -> resolv.conf ->
persist via a launchd job, with KeepAlive false since it runs a script
that exits. Also covers reverting, and the ifconfig-only path for a
throwaway address with its overwrite caveat stated.
Command-Reference now says why ipconfig has only two subcommands and
links here.
NOT YET TESTED ON HARDWARE -- derived from source; the test VM was down.
Document the wlan tool; Command-Reference named it without showing it
Command-Reference had a wlan section that described who owns wireless and
never showed a single command. It now carries the five verbs.
Adds Wireless-Networking, drawn from wlan(8) and wland(8):
- the scan / connect / status workflow with real output
- all five commands, and the optional trailing interface argument
- networks are remembered on connect, so wland autojoins at next boot
- the associated vs connected distinction, which the man page rightly
calls the most confusing thing about 802.11: at "associated" the port
is not keyed, ipconfigd holds DHCP on purpose, and a stuck
"associated" is nearly always a wrong passphrase
- the three diagnostics with what each actually means
- plaintext passphrases in the known-networks plist, stated plainly
- the two real limits: no WPA-Enterprise, and scan under-reports on the
first call because it sleeps rather than waiting for scan-complete
Linked from Home and the sidebar.
Drop the leading H1 from every page
GitHub renders the page name as a heading on every wiki page, so a file
that also opens with "# Page Name" prints its title twice. All eleven
pages did.
Home's H1 read "NextBSD" rather than "Home", so it was not a literal
duplicate, but it goes too -- eleven pages with one convention beats ten
plus an exception, and the bold opening sentence works as the lead.
Section headings inside the pages are untouched.
Reword the two "meet" sentences in plain terms
"the virtual GPUs you actually meet in a VM" and "which is how most
people meet it" both used meet in a sense that does not survive a first
reading. Now: "the GPUs a VM presents" and "Most people run NextBSD in a
VM".
Add Hardware Support; drop the duplicated Home entry from the sidebar
Hardware-Support covers what the kext story actually is: KMS graphics for
the virtual GPUs (BochsGraphics, VirtIOGraphics on both arches,
VBoxGraphics), the physical-GPU kexts (Intel, AMD, Radeon, NVIDIA), the
shared DRM helper kexts that drm-kmod does not ship, and IntelWiFi /
IntelEthernet whose matching tables are generated from driver source.
It states the limits plainly -- the graphics series is experimental, the
kernel-extensions package is amd64-only today, and coverage is narrow.
Home's intro gains a matching sentence, since hardware was the one part of
the stack the opening paragraph never mentioned.
The sidebar listed Home under "Start here", which duplicated the page title
GitHub renders on every wiki page and read oddly besides -- Home is the
root, not a step. It becomes a standalone link above the sections.
Build out the wiki as user-facing documentation
Adds nine pages and a sidebar, drawn from the repo READMEs, PORTING notes,
the shipped man pages and the userland source tree.
Home welcome, navigation, the three surprises
Getting-Started download, verify, boot under QEMU, log in
Installing-NextBSD nextbsd-installer walkthrough
Installing-Packages pkg repo config, NextBSD-everything
Command-Reference Darwin commands with their man sections
Service-Management-with-launchd plists, launchctl, the foreground trap
Filesystem-Layout four-domain model, empty /boot/kernel
How-NextBSD-Differs the BSD comparison table, boot diagram
Project-Repositories build chain and who owns what
The existing UTM guide keeps its content and gains a title, an intro and
cross-links. Its page name contains parentheses, so links to it use
angle-bracket destinations -- a bare ](Apple-Silicon-Mac-(UTM)-Guide)
terminates at the first close paren and renders broken.