Hi Ingo, > Date: 2026-10-11 20:57:00+0200 > From: Ingo Schwarze > > Hello, > > i'm answering here because Alejandro is asking me directly. > However, please take my comments with a grain of salt because > this whole topic is far out of my comfort zone, and i have > never worked on low-level hardware support. Thanks! > My naive impression is that all the mentioned functions are entirely > anachronistic. If Daniel is correct that these functions are > intended to provide mechanisms "to allow user programs to directly > communicate with hardware through I/O ports" then i suspect that > goal as a whole is completely misguided and opposed to what the > point of having any operating system at all is in the first place: > controlling hardware access and making sure that userland *cannot* > directly manipulate hardware. > > I searched the entire source code of the OpenBSD operating system, > both kernel and userland, and failed to find anything that uses > these functions. In the Xenocara tree, which contains the X11 > implementation used by OpenBSD, there is one reference in a highly > obscure driver, vmmouse(4) = VMware Mouse input driver, but > looking at /usr/X11R6/lib/modules/input/vmmouse_drv.so, i do not > see it actually used, so i suspect it is disabled by the configure > script. There is another reference in xfree86/os-support/bsd/i386_video.c, > but it's only conditionally compiled, so it seems likely that is also > disabled. Admittedly, searching very large codebases like this > is not trivial, so i might have overlooked something. > > To summarize, i cannot say why OpenBSD retained i386_iopl(2) > and amd64_iopl(2). It seems possible to me it was an accident, > and deleting it was merely forgotten. Looking through the > entire commit history of these functions, my impression is > that since these functions were first provided in OpenBSD > almost exactly 31 years ago, exactly one persion ever changed > anything substantial with respect to them, and that single > change happened in 1998. Such a low level of activity often > occurs when the functionality in question is obsolete and unused. > > If you think that would be helpful, i could ask around inside the > OpenBSD developer community whether i386_iopl(2) and amd64_iopl(2) > should be deleted, or whether they still serve any purpose, and if > so, which purpose, and report back to you. Yes, it'd be good to get confirmation from them. > One thing is abundantly clear: in normal multi-user operation, > amd64_iopl(2) cannot be used on OpenBSD because OpenBSD runs > with securelevel(7) = 1 by default and because OpenBSD runs > with sysctl(8) machdep.allowaperture=0 by default, and i don't > recall ever needing allowaperture for anything for more than > a decade now. Have a lovely night! Alex > Yours, > Ingo > > -- > Ingo Schwarze > http://www.openbsd.org/ > http://mandoc.bsd.lv/ --