Question

I was working on an embedded program using C.

There are tons of hardware macros like

#ifdef HardwareA 
do A 
#endif

It’s not readable, and hard to cover all the different paths with unit tests.

So, I decided to move the hardware related code to arch folders, and using macros in the makefile to decide which arch folder is linked. Like in the Linux kernel code.

But when I saw the Linux kernel, I noticed there are so many duplicates in the arch folders.

How do they make the changes to all related hardware when a bug was found in one hardware, but might affect all others?

I think doing this way will inevitably bring duplicates into the code base.

Does anyone have experience with this type of problem?

How to unit test on code which has lots of hardware macros?

Refactoring the code to move hardware macros off source code?

Answer 1

It sounds like you are replacing a function like this:

somefunc()
{
    /* generic code ... */

    #ifdef HardwareA 
    do A 
    #endif

    /* more generic code ... */
}

with multiple implementations, one in each arch folder, like this:

somefunc()
{
    /* generic code ... */

    /* more generic code ... */
}

somefunc()
{
    /* generic code ... */

    do A 

    /* more generic code ... */
}

The duplication of the generic code is what you’re worried about. Don’t do that: instead, have one implementation of the function like this:

somefunc()
{
    /* generic code ... */

    do_A();

    /* more generic code ... */
}

..and then implement do_A() in the arch folders: on Hardware A it has the code for that hardware, and on the other hardware, it is an empty function.

Don’t be afraid of empty functions – if you make them inline functions defined in the arch header file, they’ll be completely optimised out.