How to Perform Low Level I/O on a Linux Device File in Python

How do I perform low level I/O on a Linux device file in Python?

The problem turned out to be with the device driver. The read() method registered with the driver's file_operations invoked copy_to_user() but then returned 0 instead of the number of bytes copied to userspace.

The C code above "worked" because it didn't actually check the return value of read() and buff was getting populated with the response.

Character device file type

You code now is just fine. It is os.O_RDWR not os.0_RDWR

import os

dev = os.open("/dev/rtlightsensor0", os.O_RDWR)
print os.read(dev,16)

Since i dont have access to your device i cant read your char device.
But on my machine,the following works on a different char device.

import os

dev = os.open("/dev/urandom", os.O_RDWR)
print(os.read(dev, 16))

Output:

b'\xca\xbe\x90\xd6\x08\xdd\x918\xbc_\x85\\6J%e'

In Python, how to open a file for writing, but do not create it if the file does not exist?

There's two ways to do this.
Either

from os.path import exists
if exists(my_file_path):
    my_file = open(my_file_path, 'w+')

if you need to trigger things based on the file existing, that's the best way.

Otherwise, just do open(file_path, 'r+')

How to open disks in windows and read data at low level?

From http://support.microsoft.com/kb/100027

To open a physical hard drive for
direct disk access (raw I/O) in a
Win32-based application, use a device
name of the form

\\.\PhysicalDriveN

where N is 0, 1, 2, and so forth,
representing each of the physical
drives in the system.

To open a logical drive, direct access
is of the form

\\.\X: 

where X: is a
hard-drive partition letter, floppy
disk drive, or CD-ROM drive.

Low-Level-Writing in C

The C language has access to files with functions fopen/fclose/fread/fwrite etc. But there is no such thing as a block device in the language (not even a device, for that matter).

POSIX on the other hand has the low level functions open/close/read/write to access to files, and have the concept of block device. These functions can be used (with care) for a block device, as long as you follow a few simple rules (block alignment, mainly) and you know the name of your device (/dev/xxx).

If you are in a non-POSIX system, such as Windows, then the OS will have a specific way to handle the block device access. In Windows, for example, you can use the CreateFile function with the device name \\.\PhysicalDrive0, \\.\C: or such.

Faking an IO Error on Linux

As far as I understand the matter, classics of TDD warn us against writing mocks/stubs for 3rd-party interfaces (including standard library), see e.g. here. The major issue is that there is usually a gap between the application code and generic-purpose 3rd-party library which is hard to tie with mock-objects. Also, that prevents you from using tests to derive the design issues.

(Even though in your case the C library is not exactly 3rd party, unit-testing means that you test the entities in isolation).

The idea is that instead you write an adaptor class that encapsulates all the low-level logic and exposes an interface close to what your application needs (and, for example, raises more meaningful exceptions, like FileIsTooBig). Then you write mock-objects in terms of your domain. As for testing the adaptor itself, it's tested with few simple system tests.

---

Related Topics