Skip to content

Notes

Jump to bottom
Pavel A. edited this page Sep 24, 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 may be bad, or not. Some of our registers are write-only, I don't know how they would react to read. Made issue #2.

  • Apropos of atomic access: the original code does nothing special for atomicity, no any acquire-release stuff. It just works because there are no concurrent threads. If a flush after write is needed on some weird architecture, it will occur automatically when the mapping is undone. A read after write may help with this, so we'll add a switch to do read-back after write. Anyway, the I/O memory we need to access must be always mapped in non-cached mode.

  • Flush after write: same as atomic access. Not needed; kernel (or the thing responsible for /dev/mem) should flush memory on munmap (explicit or automatic).

  • 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 reads/writes be used instead of mmap on /dev/mem? A: No, mmap is the way. Reads/writes are deprecated.

Other variants of devmem and similar tools

Clone this wiki locally