Re: dummy help on io

From: Randy.Dunlap
Date: Sun Dec 12 2004 - 21:23:00 EST

Gene Heskett wrote:
On Sunday 12 December 2004 19:11, Randy.Dunlap wrote:

Gene Heskett wrote:


I've ordered the device drivers book from O-Reilly but it will be
a few days getting here.

Get it online:

Thanks, but my printer is down, I mde the mistake of installing
cups-1.1.22. But I'll go get it anyway.

Sure, just look at it on-screen (or print very selected
pages of it).

I'm trying to mod the GPL'd archive PIO.tar.gz, so it will build a
driver for a pci card with 3 each 82C55's on it, and I *think* I'd
have it working with the first of the 3 chips if I could figure
out what to do about using the call "iopl(3);" on installing
the driver, and conversely an "iopl(0);" at rmmod time.

Where is that coming from? I don't see it in the tarball
or the web site (if I'm looking at the right place).


I'm told this is required to gain access perms to addresses above
0x3FF. The call "ioperm" is used below that I've been told.

iopl() and ioperm() are userspace calls that call (g)libc.
The kernel doesn't call them.

So my driver module does need them?

A kernel driver (whether built into vmlinux or a loadable
module) cannot use them and does not need them.

Unforch, an "insmod PIO io=0xf100" (where the card is addressed
at currently) is spitting out an "unresolved symbol" error for the
iopl call.

Being a rank beginner at "pc" hardware, can someone give me a
checklist of things I've probably left out please?

Can you put the iopl() call into your app instead?

I can try it in the examples demo.c which I've modified to run
the motor 10 revolutions, if it runs. 1 step/sec. That runs
without any errors *if* I take the iopl() back out of the driver
and insmod it.

or into a shell script that forks the app (since the iopl
man page says: Permissions are inherited by fork and exec.)

Kernel is 2.4.25-adeos. With the module "rtai" inserted when emc
is running for realtime control purposes.

The card is pure hardware, no bios, only address decoding that
can set the base address anyplace in the first 64k of address
space in a step of 4 sequence from 0xnn00-0xnn0C for the 4
ports of chip 1, 0xnn10-1C for chip 2, etc, where the nn is the
dipswitch setting.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at