/dev/port

[Antonio]

Hi, I can't understand the behavior of my parallel port

I'm going to read 3 bytes starting at 0x378 (888)

# dd if=/dev/port bs=1 skip=888 count=3 | hd
3+0 records in
3+0 records out
3 bytes (3 B) copied, 0.000126273 s, 23.8 kB/s
00000000 04 78 0c |.x.|
00000003

now I write something over the first byte...

# echo -n A | dd of=/dev/port bs=1 seek=888 count=1
1+0 records in
1+0 records out
1 byte (1 B) copied, 0.00206702 s, 0.5 kB/s

and dev/port changes accordingly

# dd if=/dev/port bs=1 skip=888 count=3 | hd
3+0 records in
3+0 records out
3 bytes (3 B) copied, 0.000141359 s, 21.2 kB/s
00000000 41 78 0c |Ax.|
00000003

but... if I unload parport modules

# rmmod lp ppdev parport_pc parport

IO ports became 0xff 0xff 0xff

# dd if=/dev/port bs=1 skip=888 count=3 | hd
3+0 records in
3+0 records out
3 bytes (3 B) copied, 0.000133537 s, 22.5 kB/s
00000000 ff ff ff |...|
00000003

and I can write nothing anymore on it

# echo -n A | dd of=/dev/port bs=1 seek=888 count=1
1+0 records in
1+0 records out
1 byte (1 B) copied, 0.0022 s, 0.5 kB/s

# dd if=/dev/port bs=1 skip=888 count=3 | hd
3+0 records in
3+0 records out
3 bytes (3 B) copied, 0.000187454 s, 16.0 kB/s
00000000 ff ff ff |...|
00000003

I can't understand why.

[Aragorn]

On Wednesday 27 October 2010 13:02 in alt.os.linux, somebody identifying
as Antonio wrote...

It is quite simple. You've unloaded the parallel port modules, so the
kernel has no way to interface with it anymore.

Still, on a system with udev, udev should then remove the "/dev/port"
device special file. Depending on the major and minor of that device
special file, it /may/ have become assigned to something else, or
perhaps nothing at all.

I'm not exactly an expert at this low-level stuff, but logic dictates
that you would indeed no longer be able to write to your parallel port
once you've unloaded the kernel driver modules for it from the kernel.
If the kernel doesn't know about a device, then as far as anything in
the operating system is concerned, such device does not exist.

--
*Aragorn*
(registered GNU/Linux user #223157)

[unruh]

That is of course not true, since the kenrel interface is simply a
writing to hardware ports. HOwever, when the parallel drivers are
unloaded they "destroy" the ports so that they are unreadable and
unwriteable until a reboot ( or until some incantation is thrown at the
ports which I have never been able to figure out) I had this problem
when I wanted to use the parallel port to read a PPS signal from a GPS.
The only sulution was to make sure tha the parallel port drivers are
never loaded in the first place. Then the ports are available for use by
other prgrams.
Arguing with the parport maintainers got nowhere-- this was a feature
that they claimed was hallowed by tradition, and they were certainly not
going to leave the ports in the same state that the drivers found them
in when they were loaded. They felt that if you once had loaded and then
unloaded the drivers, you should never ever again be able to use the
ports ( until a reboot). Maybe punishment for not using their brilliant
software.

>
> Still, on a system with udev, udev should then remove the "/dev/port"
> device special file. Depending on the major and minor of that device
> special file, it /may/ have become assigned to something else, or
> perhaps nothing at all.
>
> I'm not exactly an expert at this low-level stuff, but logic dictates
> that you would indeed no longer be able to write to your parallel port
> once you've unloaded the kernel driver modules for it from the kernel.

The parport drivers are simply software that writes to certain ports,
etc. It is not magic.

> If the kernel doesn't know about a device, then as far as anything in
> the operating system is concerned, such device does not exist.
>

But the kernel DOES know about the absolute addresses of ports.

[Antonio]

unruh wrote:

> writing to hardware ports. HOwever, when the parallel drivers are
> unloaded they "destroy" the ports so that they are unreadable and

GREAT! blacklisting parport modules, works fine.

> unwriteable until a reboot ( or until some incantation is thrown at the

this incantation is probably somewhere inside the 3500 lines of
driver/parport_pc.c

thanks for all.

[Antonio]

Aragorn wrote:
> It is quite simple. You've unloaded the parallel port modules, so the
> kernel has no way to interface with it anymore.
>

by careful

/dev/port is not a standard device, like /dev/lp0 or /dev/ttyS0 are

[Antonio]

> this incantation is probably somewhere inside the 3500 lines of
> driver/parport_pc.c

or in functions defined in include/linux/parport.h