Re: Suggestions for an improvement to the man page "iopl - change I/O privilege level".

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

Hi Daniël,

I'm replying with the mailing list in CC.  This will transform the
message into plain text.


Have a lovely night!
Alex

> Date: 2026-08-11 17:19:31+0000
> From: Daniël Hörchner <dbjh@gmx.net>
>

> Hello,
> 
> 
> I have some feedback and suggestions to improve the man page of
> "iopl - change I/O privilege level".
>  
> The purpose of iopl() is not clearly explained. iopl() is a
> straightforward way to allow direct access to all I/O ports from
> user mode, when it is passed the argument 3. In practice, it is
> always passed the argument 3.
>  
> The description ends with the following paragraph:
> "This call is deprecated, is significantly slower than ioperm(2),
> and is only provided for older X servers which require access to
> all 65536 I/O ports.  It is mostly for the i386 architecture.  On
> many other architectures it does not exist or will always return
> an error."
>  
> The (dubious) claim that iopl() is slower than ioperm() is
> completeley irrelevant, as the most common use case involves
> calling iopl() or ioperm() once during program initialization.
>  
> Compared to iopl(), ioperm() is more restrictive. In the past
> NetBSD, FreeBSD, OpenBSD and DragonFly BSD provided analogous
> implementations in the form of i386_set_ioperm(). OpenBSD/x86_64
> provided amd64_set_ioperm(). They served the same purpose as
> ioperm() on Linux/x86{_64}, i.e. controlling access to specific
> I/O ports.
> However, as far as I can tell, all mentioned BSDs have dropped
> that functionality, but NetBSD and OpenBSD retained their version
> of iopl(): i386_iopl(), x86_64_iopl() (NetBSD/x86_64) and
> amd64_iopl() (OpenBSD/x86_64). FreeBSD and DragonFly BSD set the
> IOPL of the relevant process to 3 in the kernel, when the process
> successfully opens /dev/io.
> In other words, the BSD projects all preferred to drop their
> versions of ioperm() in favor of continuing to provide user
> programs a way to change the IOPL. It is interesting and perhaps
> noteworthy that the Linux project appears to head in the opposite
> direction.
>  
> As I stated above the purpose of iopl() goes beyond providing
> access only to older X servers. It is a mechanism to allow user
> programs to directly communicate with hardware through I/O ports.
> Whether this functionality is sufficient for modern hardware is
> outside the scope of describing iopl().
>  
> Kind regards,
> Daniël Hörchner

> Hi Alex,
> 
> Thank you for your quick reply. I am taken aback that HTML e-mail
> is still this insurmountable technological hurdle. I have not
> used local (non browser based) e-mail clients in 9 years. I
> cannot justify the time to set up a proper e-mail client right
> now, just to send a plain text e-mail. I am sorry and apologize
> if you are unable to read this message. I have attached a copy as
> text file (e-mail.txt). I have also attached the original e-mail
> as text file (iopl-manpage-feedback.txt).
> 
> Kind regards,
> Daniël Hörchner


-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]