In order to use inb_p() and ou tb_b(), not only did I have to compile with optimization on and use ioperm() to allow access to those ports, I also had to use ioperm() to allow access to port Ox80. This is because the *b_p () functions use port Ox80 to slow down port access.
I was also lucky in that all my ports were less than Ox3ff. To access ports higher than Ox3ff, you either need to use /dev/port (as will be described below) or, for fastest access, use the iopl() function to set your I/O protection level to “ring 3”, the same as the kernel. This is unfortunate (although there are good reasons for it; read kernel/ioport.h if you care), because it means that you can access any port at all, and if you access the wrong one through some programming error, you may much more easily mess up the entire machine. Imagine what will happen if your program accidentally writes “random” values to one of the I/O ports that controls the hard drive. At “ring 3”, code is nearly as powerful as the kernel, and so one of the advantages of a user-level driver is gone.
If you are going to do something as dangerous as use iopl() to put your code in ring 3, you should probably know how to read kernel source code, so I will simply refer you to kernel/ioport.h for details. System calls are called sys_name within the kernel, so look for sys iopl().
Note that I used the ioperm() function to read and write directly from and to the ports with the inb_p() and outb_b() functions, and that this function requires that the code run as root. Another option is to read and write from /dev/port. This is a little slower, but has the advantage that the code does not require root permissions to run; just read and write permission to /dev/port. Simply use lseek() to seek to the address of the port you want to read from or write to, and read() or write() a single byte to the file. If you want to read or write again, you need to use lseek() again. If you make a group called port and make /dev/port readable and writable by group port, then any user in group port can use user-space device drivers written in this way without the programs being setuid root.
Another way to access /dev/port is to use mmap() to map it into some memory space. Then you can write to ports directly at the memory address you map them to. See the section on memory mapping, below, to learn how to map files; the details (other than the filename) are the same. Since perl can use the mmap() call, it is possible to write device drivers that access /dev/port and /dev/mem as perl scripts.
Other devices may need to be accessed at some place in physical memory. The first 3GB of physical memory (if you have more memory than that and don't know how to access the 4th gigabyte, you don't have my sympathy...) can be accessed through /dev/mem. The sidebar (at left on page 20) gives a rough version of the mmap() code from svgalib, which, like XFree86, is a user-space device driver for video cards:
The code first opens /dev/mem, then allocates enough memory to map the section of /dev/mem it wants into, and then maps /dev/mem over the already allocated memory. Once this has been successfully done, whenever that process writes to or reads from that memory, it is writing to or reading from physical memory at the address that /dev/mem was mapped to.
Since perl can use the mmap() call, it is possible to write device drivers that access /dev/port and /dev/mem as perl scripts. If you don't already use perl, it's probably not worth it, but if you do use perl, you may find the idea intriguing. If you try it, I'd like to know how it works for you, and if you have any hints, I may pass them on to the readers of this column. Similarly, it is technically possible (although in practice “too clever by half” and rather slow) to write a device driver as a shell script, by using dd to read and write ports. Just to be contrary, I worked on such a driver, and found that the chief problems are the lack of binary bit-wise operations and lack of real binary data. I am not distributing this shell script; anyone who seriously cares about playing in this way can cook up their own based on the userlp.c file presented in this column. If you get it to work reliably, please notify me, and I may print your version in a future Kernel Korner.
Michael K. Johnson is the editor of Linux Journal, and is also the author of the Linux Kernel Hackers' Guide. He welcomes your comments.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python