Displaying 20 results from an estimated 2000 matches similar to: "[PATCH v4 00/10] x86: Support compiling out userspace IO (iopl and ioperm)"
2013 Oct 22
9
[PATCH 0/3] x86: Support compiling out userspace I/O (iopl and ioperm)
This patch series makes it possible to compile out the iopl and ioperm system
calls, which allow privileged processes to request permission to directly poke
I/O ports from userspace.
Nothing on a modern Linux system uses these calls anymore, and anything new
should be using /dev/port instead, or better yet writing a driver.
Copying the bloat-o-meter stats from the final patch:
32-bit
2013 Oct 22
9
[PATCH 0/3] x86: Support compiling out userspace I/O (iopl and ioperm)
This patch series makes it possible to compile out the iopl and ioperm system
calls, which allow privileged processes to request permission to directly poke
I/O ports from userspace.
Nothing on a modern Linux system uses these calls anymore, and anything new
should be using /dev/port instead, or better yet writing a driver.
Copying the bloat-o-meter stats from the final patch:
32-bit
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 Mar 11
2
[PATCHv2 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 Mar 11
2
[PATCHv2 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
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
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
2014 Oct 29
2
[PATCH v3 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
2014 Oct 29
2
[PATCH v3 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
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
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
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
2013 Oct 26
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
I/O from userspace is used to implement usermode virtio driver(s).
This has been done independently by Intel, 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,
>
2013 Oct 26
1
[PATCH 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
I/O from userspace is used to implement usermode virtio driver(s).
This has been done independently by Intel, 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,
>
2013 Oct 31
1
[PATCH 1/3] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
Hi Josh,
Since you added me to the CC, I had a look... Comments inline
On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote:
> 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
2013 Oct 31
1
[PATCH 1/3] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling
Hi Josh,
Since you added me to the CC, I had a look... Comments inline
On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote:
> 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
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
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
2013 Oct 22
0
[PATCH 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