Displaying 20 results from an estimated 26 matches for "x86_ioport".
2014 Nov 03
2
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
> > 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.
>
> Should kernel drivers really express dependencies that only their
> (current instances of) corresponding userspace componen...
2014 Nov 03
2
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
> > 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.
>
> Should kernel drivers really express dependencies that only their
> (current instances of) corresponding userspace componen...
2014 Nov 03
1
[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 at 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...
2014 Nov 03
1
[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 at 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...
2014 Nov 03
0
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Mon, Nov 03, 2014 at 03:27:48PM +0000, 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 these days be the only mainstream one that needs the select
> > > adding.
> >
> > Should kernel drivers really express dependencies that only their
> > (current instances of) corresp...
2014 Nov 03
0
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
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 these days be the only mainstream one that needs the select
>>> adding.
>>
>> Should kernel drivers really express dependencies that only their
>> (current instances of) corresponding u...
2014 Nov 03
0
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
...ne Thousand Gnomes wrote:
> On Sun, 2 Nov 2014 09:33:01 -0800
> Josh Triplett <josh at 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 usersp...
2014 Nov 02
1
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
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.
In addition to saving a significant amount of space, this also reduces
the size of several major kern...
2014 Nov 02
1
[PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
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.
In addition to saving a significant amount of space, this also reduces
the size of several major kern...
2013 Oct 31
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
Hi Josh,
On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote:
> On the vast majority of modern systems, no processes will use the
> userspsace I/O syscalls, iopl and ioperm. Add a new config option,
> CONFIG_X86_IOPORT, to support configuring them out of the kernel
> entirely. Since these syscalls only exist to support rare legacy
> userspace programs, X86_IOPORT does not depend on EXPERT, though it does
> still default to y.
>
> In addition to saving a significant amount of space, this also redu...
2013 Oct 31
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
Hi Josh,
On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote:
> On the vast majority of modern systems, no processes will use the
> userspsace I/O syscalls, iopl and ioperm. Add a new config option,
> CONFIG_X86_IOPORT, to support configuring them out of the kernel
> entirely. Since these syscalls only exist to support rare legacy
> userspace programs, X86_IOPORT does not depend on EXPERT, though it does
> still default to y.
>
> In addition to saving a significant amount of space, this also redu...
2014 Nov 02
12
[PATCH v4 00/10] x86: Support compiling out userspace IO (iopl and ioperm)
...n in copy_thread to make subsequent
changes easier. The second patch simplifies the complex calculation of the TSS
segment limit, which also makes it easier to change in the last patch. Patches
3-9 introduce helpers to make it easier to compile out IO. The last patch adds
and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO.
v3 had patches 3-10 as a single patch; v4 splits out the various helpers and
macros into separate patches, as requested by Thomas Gleixner.
I've verified that this compiles after each patch.
Josh Triplett (10):
x86: process: Unify 32-bit and 64-bit co...
2014 Nov 02
12
[PATCH v4 00/10] x86: Support compiling out userspace IO (iopl and ioperm)
...n in copy_thread to make subsequent
changes easier. The second patch simplifies the complex calculation of the TSS
segment limit, which also makes it easier to change in the last patch. Patches
3-9 introduce helpers to make it easier to compile out IO. The last patch adds
and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO.
v3 had patches 3-10 as a single patch; v4 splits out the various helpers and
macros into separate patches, as requested by Thomas Gleixner.
I've verified that this compiles after each patch.
Josh Triplett (10):
x86: process: Unify 32-bit and 64-bit co...
2013 Oct 22
0
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
On the vast majority of modern systems, no processes will use the
userspsace I/O syscalls, iopl and ioperm. Add a new config option,
CONFIG_X86_IOPORT, to support configuring them out of the kernel
entirely. Since these syscalls only exist to support rare legacy
userspace programs, X86_IOPORT does not depend on EXPERT, though it does
still default to y.
In addition to saving a significant amount of space, this also reduces
the size of several m...
2014 Mar 11
0
[PATCHv2 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
On the vast majority of modern systems, no processes will use the
userspsace I/O 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.
In addition to saving a significant amount of space, this also reduces
the size of several major kern...
2013 Oct 26
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
...tel, Brocade/Vyatta, and 6Wind.
Sorry, it has to stay.
On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote:
> On the vast majority of modern systems, no processes will use the
> userspsace I/O syscalls, iopl and ioperm. Add a new config option,
> CONFIG_X86_IOPORT, to support configuring them out of the kernel
> entirely. Since these syscalls only exist to support rare legacy
> userspace programs, X86_IOPORT does not depend on EXPERT, though it does
> still default to y.
>
> In addition to saving a significant amount of space, this also reduc...
2013 Oct 26
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
...tel, Brocade/Vyatta, and 6Wind.
Sorry, it has to stay.
On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote:
> On the vast majority of modern systems, no processes will use the
> userspsace I/O syscalls, iopl and ioperm. Add a new config option,
> CONFIG_X86_IOPORT, to support configuring them out of the kernel
> entirely. Since these syscalls only exist to support rare legacy
> userspace programs, X86_IOPORT does not depend on EXPERT, though it does
> still default to y.
>
> In addition to saving a significant amount of space, this also reduc...
2014 Oct 29
4
[PATCH v3 1/3] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
The 32-bit and 64-bit versions of copy_thread have functionally
identical handling for copying the I/O bitmap, modulo differences in
error handling. Clean up the error paths in both by moving the copy of
the I/O bitmap to the end, to eliminate the need to free it if
subsequent copy steps fail; move the resulting identical code to a
static inline in a common header.
Signed-off-by: Josh Triplett
2014 Oct 29
4
[PATCH v3 1/3] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
The 32-bit and 64-bit versions of copy_thread have functionally
identical handling for copying the I/O bitmap, modulo differences in
error handling. Clean up the error paths in both by moving the copy of
the I/O bitmap to the end, to eliminate the need to free it if
subsequent copy steps fail; move the resulting identical code to a
static inline in a common header.
Signed-off-by: Josh Triplett
2014 Oct 29
0
[PATCH v3 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote:
> On the vast majority of modern systems, no processes will use the
> userspsace I/O 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.
>
> In addition to saving a significant amount of space, this also reduces
> t...