| | |
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: 2
Reputation:
Solved Threads: 1
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 |
* adobe ansi api array binarysearch centimeter changingto char character cm convert copyanyfile copyimagefile copypdffile creafecopyofanytypeoffileinc createcopyoffile createprocess() csyntax database directory feet fflush fgets file floatingpointvalidation forloop frequency function givemetehcodez global grade graphics gtkgcurlcompiling gtkwinlinux hacking highest histogram homework i/o infiniteloop input interest intmain() iso kernel keyboard kilometer linked linkedlist linux linuxsegmentationfault list looping loopinsideloop. lowest match meter microsoft mqqueue mysql oddnumber odf open openwebfoundation pattern pdf posix power process programming pyramidusingturboccodes radix read recv recvblocked repetition research reversing scheduling segmentationfault send sequential single socket socketprogramming stack standard string suggestions threads turboc unix urboc user voidmain() whythiscodecausesegmentationfault win32api windows.h windowsapi






