As most (all?) of you probably know, there are quite a few interesting
devices that attach to the parallel port of the PC that aren't
printers. Two that I have experience with directly are a programmer
for Microchip PIC's and the PromICE ROM emulator from Grammar Engine.
I've used both of these with Linux. I modified the software for the
PromICE to use ioperm() and then do I/O directly from user space. For
the PIC programmer, I found software on the 'net that used /dev/port
to do the I/O to the port.
The reason I'm writing this message is because I'm dissatisfied with
both methods. They both require the application program to be run with
root permissions (or opening up the permissions on /dev/port). And
the applications become hardware specific.
I think it would be better if the equivalent of inb & outb access to
the port could be controlled by the permissions of /dev/lp[012].
I've thought of two methods of doing this:
1. ioctl()'s to the driver to do the equivalent of the inb's and
outb's. Has the advantage of providing some portability -- if the
printer port in question has the same I/O capabilities as the standard
PC port, but functions differently, you can translate in the driver.
It does have the disadvantage of adding more overhead to the I/O to
the port, which could screw up devices with critical timing issues
(but if the timing is that critical, shouldn't you be writing your own
driver anyway?). I note that there already seems to be an ioctl() to
read the status bits in the driver right now.
2. an ioctl() to the driver that does the equivalent of the ioperm()
call, but will only open up the I/O addresses for this port. Gets you
quicker timing because you can do the I/O straight from user space,
but loses the portability.
Of the two options, I probably prefer option 1.
For either option (or both), if it's the general opinion that this
sort of access needs to be separated (permissions wise) from the usual
sort of printer port access, it could be done with separate minor
numbers (such as done for /dev/tty* & /dev/cua*).
I run production kernels, not development kernels, but I did download
2.1.39 to look at its lp driver to see if anything like this was
added. If it was, I missed it.
So: If I'm posting this question to the wrong place, tell me! If this
has already been discussed, or done, or shot down, please enlighten me
:-). Otherwise, does the idea seem reasonable and acceptable to the
linux kernel developer community? If so, I can and will do the work
-- heck, anyone reading this could probably do it in their sleep. And
does anyone think it would need the separate minor numbers?
--> Steve Wahl, steve@pro-ns.net or steve@astrocorp.com