lkml.org 
[lkml]   [2014]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Sun, 2 Nov 2014 09:33:01 -0800
Josh Triplett <josh@joshtriplett.org> wrote:

> On the vast majority of modern systems, no processes will use the
> userspsace IO syscalls, iopl and ioperm. Add a new config option,
> CONFIG_X86_IOPORT, to support configuring them out of the kernel
> entirely. Most current systems do not run programs using these
> syscalls, so X86_IOPORT does not depend on EXPERT, though it does still
> default to y.

This isn't unreasonable but there are drivers with userspace helpers that
use iopl/ioperm type functionality where you should be doing a SELECT of
X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick
scan it may these days be the only mainstream one that needs the select
adding.

Some X servers for legacy cards still use io port access. There are also
a couple of other highly non-obvious userspace users that hang on for
some systems - eg some older servers DMI and error records can only by
read via a real mode BIOS call so management tools have no choice but to
go the lrmi/io path.

Still makes sense IMHO.

From a code perspective however you could define IO_BITMAP_LONGS to 0,
add an IO_BITMAP_SIZE (defined as LONGS + 1 or 0) and as far as I can see
gcc would then optimise out a lot of the code you are ifdeffing

Alan


\
 
 \ /
  Last update: 2014-11-03 13:41    [W:0.070 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site