PREV_LEC | NEXT_LEC

What You Will Learn

• The prototype of the read() file operation and what each parameter does
• How to correctly signal end-of-file to user space
• How copy_to_user() safely returns kernel data to an application
• How to add a working read() method to the ep_chardev driver
• How to build, load, and verify the driver with real commands

Prerequisites

• Lecture 4.7 of this free linux kernel development course, which added the write() method to ep_chardev
• A Linux machine on kernel 6.x with kernel headers installed
• Comfort with pointers and basic C structs

The read() Method Prototype

buf is the user-space destination buffer, count is how many bytes the caller is requesting, and f_pos tracks the current read position. The return value is the number of bytes actually read, 0 to signal end-of-file, or a negative error code.

How Data Flows From Kernel to App

Steps Inside a read() Implementation

1. Check for end-of-file. If *f_pos is already at or past the amount of valid data, return 0 so callers like cat know to stop.
2. Clamp the count. Never let a read request pull more bytes than actually exist past the current offset.
3. Lock the shared resource. Protect the buffer from concurrent access with a mutex, same as in write().
4. Copy to user space. Use copy_to_user(), which validates the destination pointer before copying.
5. Advance the position and return. Update *f_pos and return the number of bytes copied.

Why copy_to_user() Instead of memcpy()

Just as with writes, the destination buffer in a read call belongs to user space and cannot be trusted as a raw pointer. copy_to_user() validates the destination range and safely handles page faults, returning the number of bytes that could not be copied.

Full Example: Adding read() to ep_chardev

This builds directly on the ep_chardev struct and buffer introduced in the previous lecture, reusing the same data_len field that write() updates.

Notice that the end-of-file check happens after acquiring the lock. This matters because another process could be writing new data via ep_write() at the exact same moment, and data_len must be read under the same mutex that protects it.

Registering the read Callback

Building and Testing the Driver

Expected output:

The second line of output confirms the driver correctly returned the stored data and then signaled end-of-file on the next call, which is why cat exits cleanly instead of hanging.

read() Return Values

Common Mistakes

• Forgetting the end-of-file check, which causes tools like cat or dd to read forever.
• Reading data_len without holding the same lock that write() uses to update it, creating a race condition.
• Dereferencing buf directly instead of going through copy_to_user().
• Returning a negative value on partial success instead of the actual byte count.

Best Practices

• Always check for end-of-file before doing any copy work.
• Share the same mutex between read() and write() when they touch the same buffer.
• Return short reads instead of failing when less data is available than requested.
• Keep the locked section limited to buffer access, not unrelated logic.

Performance and Security Considerations

A single mutex shared between read() and write() is simple and correct but can become a bottleneck under heavy concurrent access; a reader-writer lock (rwlock_t or rw_semaphore, covered later in this course) can help when reads vastly outnumber writes. On the security side, never trust count or assume the destination buffer is large enough — copy_to_user() protects the kernel, but a clamped count protects your device’s data boundaries too.

Summary

• The read() file operation copies kernel data out to a user-space buffer using copy_to_user().
• Return 0 to correctly signal end-of-file.
• Clamp count so you never read past valid data.
• Share locking with write() to avoid race conditions on shared state.

FAQ

Conclusion

With read() now in place alongside write(), the ep_chardev driver can fully exchange data with user space. The next lecture in this free embedded linux course covers the llseek() method, which lets applications move the read/write cursor to any position in the device.

PREV_LEC | NEXT_LEC