Skip to content

Notes

Jump to bottom
Pavel A. edited this page Oct 13, 2015 · 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. Made 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, etc.

  • Cached or non-cached: the "owner" of the memory region is responsible for this. All we see is single plain address space.

  • 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 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