How can I emulate a memory I/O device for unit testing on linux?

Question

How can I emulate a memory I/O device for unit testing on Linux?

I'm writing a unit test for some source code for embedded deployment.

The code is accessing a specific address space to communicate with a chip.

• I would like to unit test(UT) this code on Linux.
• The unit test must be able to run without human intervention.
• I need to run the UT as a normal user.
• The code must being tested must be exactly the source code being run on the target system.

Any ideas of where I could go for inspiration on how to solve this?

Can an ordinary user somehow tell the MMU that a particular memory allocation must be done at a specific address. Or that a data block must be in a particular memory areas?

As I understand it:

• sigsegv can't be used; since after the return from the handler the same mem access code will be called again and fail again. ( or by accident the memory area might actually have valid data in it, just not what I would like)

  Thanks

  Henry

Answer 1

AFAIK you need to create a block device (I am not sure whether character device will work). Create a kernel module that maps that memory range to itself. create read/write function, so whenever that memory range is touched, those read/write functions are called.

register those read/write function with the kernel, so that whenever there is read/write to those addresses, kernel is invoked and read/write functionality is performed by kernel on behalf of user.

Answer 2

First, make the address to be read an injected dependency of the code, instead of a hard-coded dependency. Now you don't have to worry about the location under test conditions, it can be anything you like.

Then, you may also need to inject a function to read/write from/to the magic address as a dependency, depending what you're testing. Now you don't have to worry about how it's going to trick the code being tested into thinking it's performing I/O. You can stub/mock/whatever the hardware I/O behavior.

It's quite difficult to test low-level code under the conditions you describe, whilst also keeping it super-efficient in non-test mode, because you don't want to introduce too many levels of indirection.

"Exactly the source code" can hide a multitude of sins, though, depending how you interpret it. For example, your "dependency injection" could be via a macro, so that the unit source is "the same", but you've completely changed what it does with a sneaky -D compiler option.