Skip to content

Notes

Jump to bottom
Pavel A edited this page Sep 4, 2016 · 4 revisions

Whys and whats

  • The original devmem does atomic reads and writes, if the address is properly aligned. This is what we want to access hardware registers.

  • However, they always do a read, even if the command specifies write. This is bad. Device registers are tricky, reads may be destructive. So we've removed the read issue #2.

  • Apropos of atomic access: the original code does nothing special for that, no any acquire-release stuff. It just works because there are no concurrent threads.

  • Also there's no special support for advanced PCI/PCIe operations like locked ops, atomic ops, RMW transactions etc.

  • Cached or non-cached memory (and other fancy attributes): the "owner" of the memory region is responsible for mmap'ping in correct mode.

  • Flush after write: we don't care. The kernel (or whatever is responsible for /dev/mem) should flush memory on munmap (explicit or automatic).

    • A read after write may help with this, so we've added a switch to do read-back after write. Anyway, the I/O memory we need to access should be always mapped in non-cached mode.

  • Protection against errors and misuse: The /dev/mem device is available only if allowed in the kernel config. Even if available, it does not let access any location - only I/O memory, only if its owner (some kernel driver) has not prohibited it. In kernel config, CONFIG_DEVMEM enables /dev/mem file; CONFIG_STRICT_DEVMEM enables restrictions (only I/O memory, etc). See linux/drivers/char/mem.c

  • Q: Should normal reads/writes be used instead of mmap on /dev/mem? A: No, mmap is the way. Reads/writes are deprecated (see kernel src.)

Other variants of devmem and similar tools

Clone this wiki locally