Feedback

My last column on using Linux seems to have struck a resonance with many of you. I got lots of feedback, but one of the most interesting was a suggestion for a possible alternative approach to getting to the I/O ports from András Zsótér. András notes that there is character device /dev/port which maps to all the hardware I/O ports. To get to a particular I/O port, use the port address ( say 0x378 ) as an offset into the device file and reposition the file pointer to that location.

So you can manipulate it in the following manner,

5#5

Again, in order for this to work, your application must be allowed read-write access on /dev/port. The device /dev/port is rather special, it is much safer to use makedev to create a new entry in /dev that has the identical major and minor device numbers and adjust the permissions on that file,

6#6

Here, /dev/io is a new device driver entry point (it points to the same code as /dev/port since the device numbers are the same), this is the name of the "file" that should be opened in the above code. In this example anyone in the group users can gain read-write access to the port (you can create a special group that not all users are members of and change the group of the device, if you want to restrict access to only some users - this is what András does for his system).

This is a clean and direct approach to getting to the ports, but it has one weakness: the management of multiple process access to the devices is problematic. Depending upon the way the system is configured and the file access flags used when the file was opened, a file is either exclusively for the use of the process or it can be shared amoung multiple process. Either choice causes problems. If the file is not shared then once a process has opened the I/O port device, no other process can get to any other ports without resorting to very special tricks. So, if you are running one program in the background that uses an A/D board at 0x320, you cannot have another program running stepper motors on the parallel port at 0x378. Alternatively, if you open the file as shared, then two different processes can get access to the same device at the same time and not know it. Consider the confusion that would be caused by two different processes trying to simultaneously initialize a device (like the 8255) that takes multiple configuration bytes that are successively written to a single register. There are ways around this, but if you are going to be making a practice of doing this sort of thing, you should probably just write and install a proper device driver.

I am also pleased to report that there is at least one more ANS Forth compiler available for Linux/Unix: gForth by Bernd Paysan.