| | |
Hardware interactions on Linux
Thread Solved |
>>Does anyone here have any tips on using inb and outb for interacting with hardware on a Linux system?
Yes -- you can not use them because the os won't let you access the ports directly.
>>Infact, inb(0x61) gives me a segfault.
Yup
Yes -- you can not use them because the os won't let you access the ports directly.
>>Infact, inb(0x61) gives me a segfault.
Yup
Last edited by Ancient Dragon; Mar 23rd, 2008 at 6:22 pm.
Don't PM me with questions -- you might get a nasty PM in response. If you have a question then post it in one of the forums.
•
•
•
•
>>Does anyone here have any tips on using inb and outb for interacting with hardware on a Linux system?
Yes -- you can not use them because the os won't let you access the ports directly.
>>Infact, inb(0x61) gives me a segfault.
Yup
I know, that's why I said modified for windows. As in replacing inb and outb with inportb and outportb.
•
•
Join Date: Aug 2009
Posts: 5
Reputation:
Solved Threads: 2
I realize that this thread is old, but it is still useful to correct an erroneous assertion about inb(), outb(), etc., especially given that Google drops people in here when looking for an answer to why these functions segfault, even when all the advice featured elsewhere is followed.
The truth is that these functions do in fact work, even under the most recent versions of the kernel (as of 8/11/09). However, they will not work from a user mode program unless the program is run as root (sudo...). It is also true that they will segfault if iopl(3) is not used. iopl(2) is not good enough. It is also true that the method of using ioperm() fails, apparently no matter how it is used. This may have worked in older kernels, but it now always gives a segfault. The only means of using these function seems to be calling iopl(3) first. (Ubuntu Interpid, 2.6.28-15-generic, x86_64 GNU/Linux)
The truth is that these functions do in fact work, even under the most recent versions of the kernel (as of 8/11/09). However, they will not work from a user mode program unless the program is run as root (sudo...). It is also true that they will segfault if iopl(3) is not used. iopl(2) is not good enough. It is also true that the method of using ioperm() fails, apparently no matter how it is used. This may have worked in older kernels, but it now always gives a segfault. The only means of using these function seems to be calling iopl(3) first. (Ubuntu Interpid, 2.6.28-15-generic, x86_64 GNU/Linux)
![]() |
Other Threads in the C Forum
| Thread Tools | Search this Thread |
#include * adobe ansi api array asterisks binarysearch centimeter changingto char character cm copyimagefile cprogramme creafecopyofanytypeoffileinc csyntax database directory dynamic execv feet fgets file fork function getlasterror getlogicaldrivestrin givemetehcodez global grade gtkgcurlcompiling gtkwinlinux hacking hardware highest histogram ide include incrementoperators infiniteloop input interest kernel keyboard kilometer license linked linkedlist linux linuxsegmentationfault list locate logical_drives looping loopinsideloop. lowest match matrix meter microsoft motherboard mqqueue number odf opendocumentformat opensource owf pattern pdf performance pointer posix probleminc process program programming radix recursion recv repetition research reversing segmentationfault sequential single socket socketprograming standard string systemcall threads turboc unix user voidmain() wab whythiscodecausesegmentationfault windows.h windowsapi






