> I was coding a driver and come to a realisation that open() system call is
> not a good place to prepare hardware for read or write operatioin, since
> dd for example uses RDWR mode to open of= device. And there is no warranty
> othewise. Generally, seems like this is a bug in Unix design, but maybe I
> do not understand something. Or maybe it's a long lining bug in dd...
>
In Unix and Linux, access to a device requires that you get a 'handle' or
file-descriptor. This is obtained with the open() call. Normally a device
keeps a record of the number of times it was opened. The device-driver
generally doesn't care who opened it, just the number of opens.
So if the number of opens is zero, the device is initialized or somehow
turned on or made ready for operation. Then the open count is incremented.
When the device is closed, the open-count is decremented. The device is
not turned off or otherwise disabled until the open-count becomes zero.
Any access to your device will always have been preceeded by an open
because you can't get a file-descriptor otherwise, read()/write() and
ioctl() require a file-descriptor, not the name of the device. So your
device will be guaranteed to have a valid file-descriptor for each of
these operations.
If your device can't be read or can't be written, there are several ways
of making the initial open() fail to prevent such operation, the easiest
being an attribute in the device file name as this traps potential
problems early. If your device can't be written, it should return an
error code. The same applies for writes.
In your cited example of O_RDWR, you probably want to allow the device
to be opened R/W (with attributes), but if the illegal operation within
the driver occurs, you return a failure code, probably -ENOSYS.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.5 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/