from small one page howto to huge articles all in one place

search text in:




Other .linuxhowtos.org sites:gentoo.linuxhowtos.org



Last additions:
using iotop to find disk usage hogs

using iotop to find disk usage hogs

words:

887

views:

209609

userrating:


May 25th. 2007:
Words

486

Views

258610

why adblockers are bad


Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

words:

161

views:

149909

userrating:


April, 26th. 2006:

Druckversion
You are here: manpages





iopl

Section: System Calls (2)
Updated: 202-0-08
Index Return to Main Contents
 

NAME

iopl - change I/O privilege level  

LIBRARY

Standard C library (libc,~-lc)  

SYNOPSIS

#include <sys/io.h>
[[deprecated]] int iopl(int level);
 

DESCRIPTION

iopl() changes the I/O privilege level of the calling thread, as specified by the two least significant bits in level. The I/O privilege level for a normal thread is 0. Permissions are inherited from parents to children. This call is deprecated, is significantly slower than ioperm(2), and is only provided for older X servers which require access to all 65536 I/O ports. It is mostly for the i386 architecture. On many other architectures it does not exist or will always return an error.  

RETURN VALUE

On success, zero is returned. On error, -1 is returned, and errno is set to indicate the error.  

ERRORS

EINVAL
level is greater than 3.
ENOSYS
This call is unimplemented.
EPERM
The calling thread has insufficient privilege to call iopl(); the CAP_SYS_RAWIO capability is required to raise the I/O privilege level above its current value.
 

VERSIONS

glibc2 has a prototype both in <sys/io.h> and in <sys/perm.h>. Avoid the latter, it is available on i386 only.  

STANDARDS

Linux.  

HISTORY

Prior to Linux 5.5 iopl() allowed the thread to disable interrupts while running at a higher I/O privilege level. This will probably crash the system, and is not recommended. Prior to Linux 3.7, on some architectures (such as i386), permissions were inherited by the child produced by fork(2) and were preserved across execve(2). This behavior was inadvertently changed in Linux 3.7, and won't be reinstated.  

SEE ALSO

ioperm(2), outb(2), capabilities(7)


 

Index

NAME
LIBRARY
SYNOPSIS
DESCRIPTION
RETURN VALUE
ERRORS
VERSIONS
STANDARDS
HISTORY
SEE ALSO





Support us on Content Nation
rdf newsfeed | rss newsfeed | Atom newsfeed
- Powered by LeopardCMS - Running on Gentoo -
Copyright 2004-2025 Sascha Nitsch Unternehmensberatung GmbH
Valid XHTML1.1 : Valid CSS
- Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 -
- Copyright and legal notices -
Time to create this page: 10.0 ms