From: Ingo Schwarze <schwarze@usta.de>
To: Alejandro Colomar <alx@kernel.org>
Cc: "Thomas Gleixner" <tglx@kernel.org>,
"Daniël Hörchner" <dbjh@gmx.net>,
linux-man@vger.kernel.org, victorm007@yahoo.com,
t.piekarski@deloquencia.de, linux-api@vger.kernel.org,
x86@kernel.org
Subject: Re: Suggestions for an improvement to the man page "iopl - change I/O privilege level".
Date: Sun, 18 Oct 2026 16:09:09 +0200 [thread overview]
Message-ID: <atTTBYFr1OvYNSjH@isnote.usta.de> (raw)
In-Reply-To: <atSsS8Pw9Pzixb7g@debian>
Hello,
Alejandro Colomar wrote on Sun, Oct 18, 2026 at 01:25:17PM +0200:
> From: Thomas Gleixner <tglx@kernel.org>
>> So in pratice these syscalls and IOCTLs are ancient ballast and any
>> modern distro should not need them anymore.
Same in OpenBSD; by default, securelevel(7) and sysctl(2) block
access to them. The most important place where they are still
occasionally used are some very old X11 video drivers that that do
not use kernel mode setting but instead use libpciaccess to access
PCI devices directly. It appears they are also used by some
coreboot-utils programs, but we did not investigate what exactly
the purpose is there. No other use case came up when i asked around
among developers.
> Thanks! I'll keep the manual pages unchanged.
An improvement resulted in OpenBSD manual pages though:
https://man.openbsd.org/?query=iopl&apropos=1 # two related pages
https://marc.info/?l=openbsd-cvs&m=179214240879202 # commit message
In general, i believe it is valuable when people adhere to standards
and take care to write portable code. However, this does not apply to
the present case of low-level hardware control where operations are
unavoidably highly system- and hardware-dependent.
Getting rid of these functions may or may not ultimately become a
goal in OpenBSD, but it appears developers working in the area
currently see no urgency. There is very little risk because these
finctions have been disabled by default for quite some time now.
Yours,
Ingo
next prev parent reply other threads:[~2026-10-18 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <trinity-4d271f4c-4816-435f-b8c9-53eef0ff29c7-1786468770978@trinity-msg-rest-gmx-gmx-live-d7f776569-bpnnk>
2026-10-11 17:18 ` Suggestions for an improvement to the man page "iopl - change I/O privilege level" Alejandro Colomar
2026-10-11 17:26 ` Alejandro Colomar
2026-10-11 18:57 ` Ingo Schwarze
2026-10-11 19:10 ` Alejandro Colomar
2026-10-15 16:54 ` Thomas Gleixner
2026-10-18 11:25 ` Alejandro Colomar
2026-10-18 14:09 ` Ingo Schwarze [this message]
2026-10-18 15:54 ` Andy Lutomirski
[not found] <trinity-ad00fce6-96e1-4b4f-8abc-98e945e01f5f-1786459267306@trinity-msg-rest-gmx-gmx-live-d7f776569-7648m>
2026-08-11 16:11 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atTTBYFr1OvYNSjH@isnote.usta.de \
--to=schwarze@usta.de \
--cc=alx@kernel.org \
--cc=dbjh@gmx.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=t.piekarski@deloquencia.de \
--cc=tglx@kernel.org \
--cc=victorm007@yahoo.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox