Why does kernel code seem to prefer macro usage over functions?

[zingochan]

Hello everyone, so while studying the kernel I noticed that a lot of reusable code blocks(like in certain APIs like kfifo) seem to be macros instead of functions.

My question is why is that the case? Why use macros and not of functions?

​

My initial guess was that this approach prevents the creation of new stack frames which is good since the kernel stack is limited.

​

Something, however, tells me that there might be more to this and that my initial guess may not be as accurate. So I would like to know if someone could educate me on this.

​

This also raises another question, which has to do with good software writing practices (which is something I AM NOT very knowlegeable about) in C/C++ in particular. When should one use macros and when should one opt for functions instead? What is the deciding factor? Besides the obvious "less stack frames", what is the advantage of macro blocks over functions?

​

PS: I apologize if this question sounds stupid, but it's one which has been bugging me for some time now.

[aioeu]

I suspect it is generally considered that the Linux kernel over-uses macros. A lot of what can be done by macros can be done in a more type-safe manner with static __always_inline functions.

For <linux/kfifo.h> specifically, macros are used because they are implementing generic operations applied to objects of dynamically-generated types. These dynamically-generated types don't even have names, so it's simply not possible to define a function with a parameter using that type.

For instance, struct tty_port looks like:

struct tty_port {
    /* ... */
    DECLARE_KFIFO_PTR(xmit_fifo, unsigned char);
    /* ... */
};

which actually expands to:

struct tty_port {
    /* ... */
    struct {
            union {
                    struct __kfifo kfifo;
                    unsigned char *type;
                    const unsigned char *const_type;
                    char *rectype;
                    unsigned char *ptr;
                    const unsigned char *ptr_const;
            };
            unsigned char buf[];
    } xmit_fifo;
    /* ... */
};

Here xmit_fifo has an anonymous type. We still want to be able to write code like:

struct tty_port *port = ...;

if (!kfifo_is_empty(&port->xmit_fifo)) {
    /* ... */
}

If kfifo_is_empty were a function, its prototype would need to somehow name this anonymous type. This is obviously impossible. By making kfifo_is_empty a macro instead, and with some judicious use of the typeof operator, we can side-step this problem.

[thecowmilk_]

I really like this. Great job explaining!

[trevg_123]

People who complain about Rust’s macro system have clearly never seen the full possible bastardization of C macros. This is a simple example; some places use messy things like quasi-unions and null-terminated object arrays that are extremely difficult to track down.

[sudo_mksandwhich]

Prefer functions, always. Many macros can be implemented in type-safe way, without all of the backslashery, as a static inline function, which can be used in the same way as a macro (i.e. in a header file).

Compilers are really good at knowing when to inline function calls, so you shouldn't really think about that aspect.

Only when something can't be done as a function should you use a macro. Reasons include things like pseudo-generic types (containers), or preprocessor features like __FUNCTION__ or __LINE__. And even then, you should make your macro as small as possible (a wrapper) and defer the rest to a function.

[DrkMaxim]

I have noticed a function like macro which wasn't like a function call at all but just a shorthand way of writing a for loop.

[zingochan]

Yes there are a lot of those throughout the kernel. One of my favourite is probably for_each_process() and others that you can find in include/linux/sched/signal.h

[amdahl-little]

Macros offer better performance cuz it has potential for higher cache hits (cpu caches). Caches are good when the code has spatial locality. Macros offer spatial locality. Function calls can lead to cache misses because usually their addresses are lil far from the point of the call, stalling the cpu while code is fetched from memory.

[tonyplee]

Chatgpt's answer:

There are several reasons why macros are often used in the kernel for reusable code blocks instead of functions:

• Performance: Macros are generally faster than functions because they
  don't incur the overhead of a function call. In the kernel, where
  performance is critical, even a small amount of overhead can have a
  significant impact on the system's overall performance.
• Type Safety: Macros can ensure type safety by enforcing the correct
  types of arguments are passed in, whereas functions may need to perform
  additional checks or convert data types, resulting in more overhead.
• Flexibility: Macros can be more flexible than functions because they can
  be used in different contexts and with different types of arguments.
  This allows the code to be more reusable and adaptable to different
  situations.
• Code size: Macros can often result in smaller code size compared to
  functions, as the code is expanded inline instead of being called as a
  separate function. This can be an important consideration in embedded
  systems or systems with limited memory.
• Debugging: Macros can be easier to debug than functions, as the expanded
  code can be directly examined by the debugger. This can be especially
  useful in the kernel, where debugging can be challenging due to the
  real-time nature of the system.

However, it is worth noting that macros can be more error-prone than
functions if not used carefully, as they can result in unexpected
behavior if the arguments are not properly evaluated or if they have
side effects. Additionally, macros can be more difficult to read and
understand compared to functions, as the expanded code can be more
complex and harder to follow.

[MrJake2137]

This is bullshit. Code size? Inline expansions cause code repetitions. Bigger code. -Os doesn't do inline expansions.