Messages in this thread | | | Date | Mon, 3 Nov 2014 12:10:49 +0000 | From | One Thousand Gnomes <> | Subject | Re: [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
| |