On Sun, 2 Nov 2014 09:33:01 -0800
Josh Triplett 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 n
> > 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 th
On 11/03/2014 07:27 AM, One Thousand Gnomes wrote:
>>> 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
On Mon, Nov 03, 2014 at 03:27:48PM +, One Thousand Gnomes wrote:
> > > 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
On Mon, Nov 03, 2014 at 12:10:49PM +, One Thousand Gnomes wrote:
> On Sun, 2 Nov 2014 09:33:01 -0800
> Josh Triplett 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
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 depe
