#!/bin/sh
# DF-5150 runtime trigger: demonstrate that the ACPI notify handler
# registered by acpi_lid_attach() with context = softc
# (sys/dev/acpica/acpi_lid.c:121-122) can never be torn down (the driver
# has no device_detach, acpi_lid.c:66-74), and that on this guest the lid
# attack surface is not instantiated: QEMU's DSDT declares no PNP0C0D
# device, so no acpi_lid device instance attaches.
#
# Run as root on the DragonFly guest. Safe: read-only probes + a failing
# kldunload. Expected outcome (see run.log):
#   - acpi_lid driver registered in the builtin kernel (kldstat -v)
#   - NO acpi_lid device instance attached (dmesg)
#   - zero PNP0C0D entries in the DSDT (acpidump)
#   - hw.acpi.lid_switch_state is owned by acpi.c (sys/dev/acpica/acpi.c:630),
#     not by acpi_lid.c (this file has no sysctl)
#   - kldunload acpi -> can't find file (builtin, no unload path)
#   - guest stays up, no fault

echo "== uname =="
uname -a
echo
echo "== acpi_lid driver registered? =="
kldstat -v 2>/dev/null | grep -i lid
echo
echo "== acpi_lid device instance attached? =="
dmesg | grep -i "acpi_lid"
echo "rc=$? (1 = no acpi_lid device instance)"
dmesg | grep -i lid
echo
echo "== PNP0C0D in the QEMU DSDT? =="
acpidump -d 2>/dev/null | grep -c PNP0C0D
echo "(0 = firmware declares no lid device)"
echo
echo "== lid sysctl owner (acpi.c, not acpi_lid.c) =="
sysctl hw.acpi.lid_switch_state
sysctl -N hw.acpi.lid_switch_state 2>/dev/null
echo
echo "== any unload path for the code owning the handler? =="
kldunload acpi
echo "rc=$?"
echo
echo "== guest alive =="
uptime