Page MenuHomeFreeBSD

vmm: Move local variables into ioctl handlers
ClosedPublic

Authored by markj on Oct 16 2025, 10:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 7, 2:16 PM
Unknown Object (File)
Fri, Nov 7, 9:07 AM
Unknown Object (File)
Tue, Nov 4, 6:08 PM
Unknown Object (File)
Mon, Nov 3, 4:13 PM
Unknown Object (File)
Wed, Oct 29, 6:30 AM
Unknown Object (File)
Tue, Oct 28, 5:21 AM
Unknown Object (File)
Mon, Oct 27, 12:16 AM
Unknown Object (File)
Sun, Oct 26, 10:26 AM

Details

Summary

Make the ioctl handlers easy to read by moving local variables into
per-ioctl blocks. No functional change intended.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Oct 17 2025, 6:15 AM
emaste added inline comments.
sys/amd64/vmm/vmm_dev_machdep.c
219

As an aside I wonder if it's reasonable to remove COMPAT_FREEBSD13 in the near future. I don't think we need to maintain backwards compat indefinitely for integrated system utilities.

263–265

I wonder if style(9) would permit

struct vm_pptdev_msi *pptmsi = (struct vm_pptdev_msi *)data;
error = ppt_setup_msi(vm, pptmsi->bus, pptmsi->slot,
    pptmsi->func, pptmsi->addr, pptmsi->msg, pptmsi->numvec);
sys/amd64/vmm/vmm_dev_machdep.c
219

Yes, probably not. Or at least we could have a sysctl which lets one opt in there, with the default being opt-out.

It's kind of hard to weigh the usefulness of backwards compat in one subsystem vs. another. Device ioctls are less important than syscalls for sure. So I'm thinking such a sysctl should be per-subsystem rather than having a blanket "enable all compat 13 code" sysctl.

263–265

I guess that'd be fine. I just kept the existing style, I'm old-fashioned and don't really like combined declaration and initialization.

This revision was automatically updated to reflect the committed changes.