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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- RSS Feeds
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
14 min 53 sec ago
- Reply to comment | Linux Journal
47 min 15 sec ago
- All the articles you talked
3 hours 10 min ago
- All the articles you talked
3 hours 13 min ago
- All the articles you talked
3 hours 15 min ago
7 hours 40 min ago
- Keeping track of IP address
9 hours 31 min ago
- Roll your own dynamic dns
14 hours 44 min ago
- Please correct the URL for Salt Stack's web site
17 hours 55 min ago
- Android is Linux -- why no better inter-operation
20 hours 11 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?