Command-Reference: DiskArbitration does not use devctl(4)
It subscribes to disk arrival and removal through the in-kernel IOKit
registry -- IOServiceAddMatchingNotification over IOREGIOCWATCH on
/dev/ioregistry (src/DiskArbitration/da_iokit_subscribe.c). libgeom is
for enumeration; the event path is IOKit.
devctl(4) is the devd interface, which is precisely what the IOKit
registry replaces -- so the old text contradicted the architecture it was
documenting. The hwregd fallback was retired too: the kernel is now the
registry.
6bb04d7
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.
10167bd
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.
3eebe7f
Updated NextBSD Wiki (markdown)
467264d
Updated NextBSD Documentation (markdown)
f466c42
Updated NextBSD Wiki (markdown)
c2f8709
Updated NextBSD Documentation (markdown)
4333610
Updated Documentation (markdown)
baf245c
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.
0ab6338
Command-Reference: point at the static-addressing tickets
Says what is coming and where to watch it, instead of either staying
silent or documenting the machine-wide ipconfigd workaround that was
pulled. Links nextbsd-userland#58 (daemon support) and nextbsd#396 (the
Network preference pane that will expose it), plus Discussions.
42d7c61
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.
26ac973
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.
a1f3956
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.
8136398
UTM guide: stop the fetch commands wrapping
Each of the four fetch lines was ~233 characters -- the same 118-character
URL prefix repeated, plus an -o path that duplicated the cd on the line
above. They wrapped into an unreadable block.
The URL splits across two short variables, so every fetch line is now
36-56 characters and the longest line in the block is 86. One fetch per
line is preserved.
Dropping -o is safe: the block already cd's to /System/Library/LaunchDaemons,
and fetch names its output from the URL.
Also tags the three shell fences as sh, so they syntax-highlight.
5cd2eb8
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.
7094ced
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".
40a4b75
Hardware: arm64 ships kexts too; drop Nmdm, which ships nowhere
NextBSD-kernel-extensions publishes for both arches -- verified by unpacking
today's packages from the continuous-<arch> release tags rather than reading
the pkg README, which still carries the stale amd64-only table.
arm64 7 kexts: VirtIOGraphics, IOGraphics, IOGraphicsExtras,
IOGraphicsShmem, TTM, DMABuf, LinuxVirtIO
amd64 17 kexts: the above plus BochsGraphics, VBoxGraphics,
IntelGraphics, AMDGraphics, RadeonGraphics,
NVIDIAGraphics595 + NVIDIACore595 + NVIDIAModeset595,
IntelWiFi, IntelEthernet
So arm64 has the complete virtio-gpu stack, which is the driver that
matters there -- UTM and QEMU give an arm64 guest virtio-gpu.
Also corrected from the same evidence: TTM and DMABuf were missing from
the shared-helpers table, NVIDIA is three kexts rather than one, and the
per-arch columns on the virtual-GPU table were guesswork.
Nmdm.kext is gone entirely. It appears in the CI workflow's kext PoC boot
test, which is where I originally read it, but it is in neither shipped
package -- zero matching entries in the amd64 archive.
Installing-Packages carried the same amd64-only claim in its package table.
a52f0c6
Installing-Packages: the repo config already ships, stop telling users to write it
build.sh:183 writes /usr/local/etc/pkg/repos/NextBSD.conf into the shipped
rootfs, alongside FreeBSD.conf and a pkg.conf pinning the ABI -- so both
repositories are live on first boot of any published .img or .iso.
The page led with "drop a config file into ...", which invented a setup step
that does not exist and implied pkg would not work until you did it. It now
leads with the three files that are already there, and puts the config text
in a "Recreating the config" section for the case where someone is
bootstrapping onto a system that did not come from a published image.
2846ff5
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.
535391e
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.
91ddbfe
Updated Apple Silicon Mac (UTM) Guide (markdown)
08a529b
Updated Apple Silicon Mac (UTM) Guide (markdown)
1f7830e
Updated Apple Silicon Mac (UTM) Guide (markdown)
05149c1
Updated Apple Silicon Mac (UTM) Guide (markdown)
49cbdc5
Updated Apple Silicon Mac (UTM) Guide (markdown)
02dcddc
Updated Apple Silicon Mac (UTM) Guide (markdown)
a68fd31
Updated Apple Silicon Mac (UTM) Guide (markdown)
33cad7c
Updated Apple Silicon Mac (UTM) Guide (markdown)
1ab93e8
Updated Apple Silicon Mac (UTM) Guide (markdown)
fef955b