Skip to content

Linux Kernel Coding Style (with MCU / RTOS Comparison)

Overview

This note summarizes practical coding conventions used in Linux kernel development, with comparison to common MCU / RTOS coding styles.

Focus areas:

  • Naming conventions
  • Structure design
  • Function design
  • Concurrency patterns
  • Observability
  • Real-world trade-offs

1. Philosophy Difference

Linux Kernel Style

  • Emphasizes readability and semantics
  • Code should read like natural language
  • Avoid redundant information (type already exists)
  • Designed for large-scale, multi-developer systems

MCU / RTOS Style

  • Often emphasizes type clarity in naming
  • Heavily influenced by hardware / register-level work
  • Naming may encode:
  • type
  • scope
  • usage
  • More flexible / team-specific

Key Difference

Linux:   semantic clarity > type hints
MCU:     type clarity >= semantic clarity

2. Variable Naming

2.1 Boolean Variables

MCU / RTOS style

bool f_ready;
bool b_enable;
bool f_irq_pending;

Linux style

bool ready;
bool enable;
bool irq_pending;
bool cache_valid;
bool polling_enable;

Why?

  • Type is already known (bool)
  • Name should describe meaning, not type
  • Cleaner in conditions:
if (data->polling_enable)
if (!data->cache_valid)

2.2 Type Prefix (Hungarian-like)

MCU style

u32Count
s32Temp
pBuffer

Linux style

unsigned int count;
int temp;
char *buf;

Reason

  • Type is already declared
  • Prefix duplicates information
  • Reduces readability in large codebases

2.3 Good vs Bad Naming

Bad (type-oriented)

u32IrqEvtCnt
bIsReady
fEnable

Good (semantic)

irq_event_count
ready
enable

2.4 Abbreviation Rules

Acceptable

irq
poll
temp
cfg
buf
dev
ret

Avoid excessive shortening

upd_intvl   (bad)
update_interval (good)

3. Structure Design

Linux Style

Group by functionality:

/* Device */
struct i2c_client *client;

/* Cached data */
bool cache_valid;
long temp_mc_cached;

/* Policy */
unsigned int min_update_interval_ms;

/* Statistics */
unsigned int irq_event_count;

/* Control */
bool polling_enable;

MCU Style

Often grouped by type or usage:

bool fEnable;
uint32_t u32Interval;
uint32_t u32Count;

Why Linux groups by function

  • Reflects system architecture
  • Easier to debug
  • Easier to extend

4. Function Naming

Linux style

myi2c_sensor_update_by_trigger_locked()
myi2c_sensor_should_update_locked()
myi2c_sensor_poll_work_callback()

Characteristics

  • Module prefix
  • Verb-based
  • Context included (_locked, _callback)

MCU style

UpdateSensor()
CheckFlag()
HandleIRQ()

Difference

Linux prefers:

what + action + context

5. Boolean Function Naming

Linux style

is_ready()
has_data()
should_update()

Avoid

check_ready()
flag_ready()

6. Function Structure

Linux style

Use early return

if (!condition)
    return 0;

Avoid deep nesting

MCU style (common)

if (condition) {
    if (sub_condition) {
        ...
    }
}

7. Locking Design

Linux pattern

mutex_lock()

update state

mutex_unlock()

schedule_work()

Rule

  • Do NOT hold lock during scheduling
  • Keep critical section minimal

MCU / RTOS

Often:

disable_irq()
update state
enable_irq()

or

take_mutex()
do everything
release_mutex()

Difference

Linux separates:

  • state protection
  • execution control

8. Workqueue vs RTOS Task

Linux

IRQ → workqueue → process
  • IRQ must be short
  • workqueue handles heavy logic

RTOS

ISR → queue → task

Similar concept, different API.

9. Error Handling

Linux

return 1;   // updated
return 0;   // skipped
return -EIO;

MCU

return OK;
return ERROR;

Linux 특징

  • Use standard error codes
  • Allow "no-op" return (0)

10. sysfs Interface Style

Linux

polling_enable
min_update_interval_ms

snake_case + descriptive

show/store pattern

xxx_show()
xxx_store()

11. Observability (Very Important)

Linux style

Explicit metrics:

irq_event_count
irq_update_count
irq_skip_count

MCU style

Often missing or minimal logging

Why Linux emphasizes this

  • Complex systems
  • Need runtime introspection
  • Debugging without JTAG

12. Policy Separation

Linux

Separate:

trigger policy
update policy
cooldown policy

Bad (mixed logic)

if (irq && time && flag && ...)

13. Readability vs Cleverness

Avoid

need_update |= condition;

Prefer

if (condition)
    need_update = true;

14. Units in Naming

Linux strongly encourages:

interval_ms
temp_mc
timeout_ms

MCU style

Sometimes missing units:

interval
temp

15. When MCU Style is Still Useful

Linux style is not always better.

MCU advantages

  • Register-level programming
  • Packed structures
  • Protocol handling

Example:

u8 reg;
u16 value;
u32 address;

16. Practical Guidelines (For This Project)

Follow Linux style for:

  • driver code
  • sysfs
  • workqueue
  • policy logic

Keep MCU habits for:

  • hardware registers
  • protocol fields
  • fixed-width data

Key Takeaways

  • Naming should express meaning, not type
  • Structure reflects system architecture
  • Separate policy from execution
  • Design for observability
  • Prefer simple and readable code