struct generic_struct {
int id;
float value;
char name[20];
int m;
};

hashtag#define GENERIC_STRUCT_STAT(m)  sizeof(((struct generic_struct *)0)->m)

int main() {
int x = GENERIC_STRUCT_STAT(m); <———-
return0;
}

𝐖𝐡𝐚𝐭 𝐰𝐢𝐥𝐥 𝐡𝐚𝐩𝐩𝐞𝐧 𝐰𝐡𝐞𝐧 𝐭𝐡𝐞 𝐦𝐚𝐜𝐫𝐨 𝐆𝐄𝐍𝐄𝐑𝐈𝐂_𝐒𝐓𝐑𝐔𝐂𝐓_𝐒𝐓𝐀𝐓(𝐦) 𝐢𝐬 𝐮𝐬𝐞𝐝?
______________________________________________________________

A) The program will crash due to dereferencing a null pointer.
B) Compilation error.
C) The size of the member m (int) will be calculated, which is typically 4 bytes on most systems.
D) The size of the entire structure generic_struct will be calculated.

#define IS_VALID (type, x) ({ \
type **z; \
typeof(x) **z2; \
(void)(&z == &z2); \ ⬅️ ➖➖➖ 𝐥𝐢𝐧𝐞 4
1; \
})

int main(int argc, char* argv[])
{

char tt = ‘c’;
float f = 10.56 ;

printf(“%d\n”, IS_VALID(int, f));
printf(“%d\n”, IS_VALID(char, tt));
return 0;
}

(void)(&z == &z2); ->
1) Is it to compare memory addresses of z and z2 at runtime 𝐎𝐑
2) to force the compiler to check type compatibility ( if z and z2 are of same type) during compilation 𝐎𝐑
3) to allocate memory for both variables in the same memory block 𝐎𝐑
4) to check the value of z and z2.

The typeof keyword emerged from fundamental limitations in the C language that became apparent as systems programs grew more complex. Here’s the story behind why it came into existence:

𝐓𝐡𝐞 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 𝐰𝐢𝐭𝐡 𝐂’𝐬 𝐓𝐲𝐩𝐞 𝐒𝐲𝐬𝐭𝐞𝐦 :
_______________________________________

1) No Generic Programming Suppport
2) Write the same code multiple times for different types
3) Use void pointers and sacrifice type safety
4) Resort to dangerous preprocessor macros

𝐔𝐧𝐬𝐚𝐟𝐞 𝐌𝐚𝐜𝐫𝐨𝐬: C macros are simple text substitutions with no type awareness, leading to infamous problems:
𝐓𝐲𝐩𝐞 𝐈𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧 𝐋𝐨𝐬𝐬:  Operations like alignment, bit manipulation, and atomic access required casting to and from types, losing type information
𝐍𝐨 𝐓𝐲𝐩𝐞 𝐈𝐧𝐟𝐞𝐫𝐞𝐧𝐜𝐞: Every variable and expression needed explicit typing, leading to verbose, error-prone code, especially with complex pointer types.

𝐓𝐡𝐞 𝐆𝐂𝐂 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐚𝐢𝐦𝐞𝐝 𝐭𝐨:
_________________________________________________________
🟢 Enable Type-Safe Generic Programming: Create a mechanism to write generic code that retained full type safety without sacrificing performance
🟢 Improve Macro Safety: Allow macros to preserve type information and avoid double-evaluation bugs
🟢 Support Systems Programming: Address the needs of low-level code like the kernel that manipulated types in ways standard C couldn’t handle

𝐖𝐡𝐚𝐭 𝐭𝐲𝐩𝐞𝐨𝐟 𝐒𝐨𝐥𝐯𝐞𝐝 𝐟𝐨𝐫 𝐊𝐞𝐫𝐧𝐞𝐥 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬
______________________________________________________
1) Architecture Portability
2) Avoiding Fragile Casts
3) Safe List Traversal
4) Atomic Operation Safety

container_of` macro allows you to find the parent structure from a pointer to one of its members. One of the most ingenious pieces of C programming in the Linux kernel.

Here’s the definition:

hashtag#define container_of(ptr, type, member) ({   \
const typeof(((type *)0)->member) *__mptr = (ptr); \
(type *)((char *)__mptr – offsetof(type, member)); })

Let’s break down:

1. Takes a pointer to a member (`ptr`)
2. The type of the container structure (`type`)
3. The name of the member within the structure (`member`)
4. Returns a pointer to the container structure

The most interesting part of the macro is:
const typeof(((type *)0)->member) *__mptr = (ptr);

Fascinating trick using a null pointer cast. Let’s analyze why this works:

– `(type *)0` casts the value 0 (NULL) to a pointer of type `type*`
– `((type *)0)->member` accesses the `member` field of this null pointer
– This doesn’t actually dereference memory (which would cause a crash), but instead lets the compiler determine the type of `member`
– `typeof()` extracts this type information
– `__mptr` is then declared as a pointer to this type and assigned the value of `ptr`

Why is This Implementation Valuable?

1. Enables C Object-Oriented Patterns

Consider this example:

struct device {
int id;       // Offset 0
char name[8];    // Offset 4
struct list_head list; // Offset 12
};

When a function receives a `list_head` pointer, it can find the containing `device` structure:

void some_list_function(struct list_head *list_ptr) {

struct device *dev;
dev = container_of(list_ptr, struct device, list);

printf(“Device ID: %d\n”, dev->id);
printf(“Device Name: %s\n”, dev->name);
}

2. Type Safety

The use of `typeof` ensures that `ptr` is of the correct type expected for the member. This provides compile-time type checking.

3. Zero Runtime Overhead

The entire macro resolves to simple pointer arithmetic. There’s no function call overhead, dynamic type checking, or any other runtime cost.

4. Maintains Encapsulation

Exposes only the necessary structures while keeping their containing structures private, enhancing modularity.

Understanding the Null Pointer Cast

The line `const typeof( ((𝐭𝐲𝐩𝐞 *)0)->member) *__mptr = (ptr);` often confuses developers new to kernel code. The null pointer (0) is specifically chosen because it’s a safe way to access type information without risking memory access.

Practical Applications
The `container_of` macro is used extensively throughout the kernel:

1. 𝐃𝐞𝐯𝐢𝐜𝐞 𝐃𝐫𝐢𝐯𝐞𝐫 𝐌𝐨𝐝𝐞𝐥: Finding device structures from their embedded kobjects
2. 𝐋𝐢𝐧𝐤𝐞𝐝 𝐋𝐢𝐬𝐭𝐬: Retrieving the containing structure from a list entry
3. 𝐑𝐂𝐔: Accessing container structures in lock-free code
4. 𝐒𝐮𝐛𝐬𝐲𝐬𝐭𝐞𝐦 𝐈𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞𝐬: Extending core functionality through composition

Two embedded engineers with identical experience sit in the same interview. Both have 2-3 years experience (applicable for freshers also), strong Linux/C skills, solid DSA knowledge.

𝐈𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 𝐐𝐮𝐞𝐬𝐭𝐢𝐨𝐧: “𝐇𝐨𝐰 𝐝𝐨 𝐲𝐨𝐮 𝐯𝐚𝐥𝐢𝐝𝐚𝐭𝐞 𝐞𝐦𝐛𝐞𝐝𝐝𝐞𝐝 𝐟𝐢𝐫𝐦𝐰𝐚𝐫𝐞 𝐪𝐮𝐚𝐥𝐢𝐭𝐲?”

❌ Candidate A: “I do thorough testing and code reviews.”
✔️ Candidate B: “I use GCOV for coverage analysis. gcc –coverage revealed
untested error paths in our SPI driver that could have caused field failures. I target 80%+ coverage for production code.”
Result: Candidate B gets the offer.

𝐖𝐡𝐲 𝐓𝐨𝐨𝐥 𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 𝐖𝐢𝐧𝐬
𝐓𝐨𝐨𝐥-𝐒𝐚𝐯𝐯𝐲 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 𝐬𝐢𝐠𝐧𝐚𝐥𝐬:
✅ Production quality experience
✅ Industry-standard practices
✅ Systematic development approach
✅ Can prevent costly field failures

𝐓𝐡𝐞 𝐄𝐚𝐬𝐲 𝐖𝐢𝐧
Complex Skills: 6+ months each (kernel internals, advanced DSA) Professional Tools: 2-3 weeks to master ⚡
Impact: Same resume + tool knowledge = 15-25% higher salary

𝐘𝐨𝐮𝐫 𝐀𝐝𝐯𝐚𝐧𝐭𝐚𝐠𝐞 𝐏𝐥𝐚𝐧

# Learn GCOV basics (1 weekend): ->
gcc –coverage -o program source.c
gcov source.c

𝐂𝐥𝐢𝐜𝐤 𝐛𝐞𝐥𝐨𝐰 𝐟𝐨𝐫 𝐝𝐞𝐭𝐚𝐢𝐥𝐬 :
https://lnkd.in/g4T_RcMq

𝐓𝐚𝐛𝐥𝐞 𝐨𝐟 𝐂𝐨𝐧𝐭𝐞𝐧𝐭𝐬-
[What is GCOV?]
[Why Use GCOV?]
[When to Use GCOV?]
[Understanding GCOV Output]
[Expert vs Novice Analysis]
[Advanced Techniques]
[Industry Best Practices]
[Practical Implementation]
𝐋𝐞𝐚𝐫𝐧 𝐦𝐨𝐫𝐞 -> https://lnkd.in/g4T_RcMq

# Build portfolio examples
# Prepare tool-focused interview talking points

𝐁𝐨𝐭𝐭𝐨𝐦 𝐋𝐢𝐧𝐞
While others study algorithms for months, you can master professional tools in weeks and immediately stand out in interviews.
Tool knowledge shows professional maturity that hiring managers need.

📢 Coming Next:
More embedded development tools that create interview advantages—static analysis, debugging utilities, profiling tools. Follow for weekly insights!

A production server hang completely because of one “atomic” operation? Here’s a real Linux kernel bug that brought down enterprise systems worldwide – A Perfect case study for understanding multi-CPU concurrency challenges!

The Linux block layer had this code in the blk-mq (multi-queue block I/O) subsystem:

// 𝐂𝐨𝐮𝐧𝐭 𝐧𝐞𝐬𝐭𝐞𝐝 𝐟𝐫𝐞𝐞𝐳𝐞 𝐨𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬
freeze_depth = atomic_inc_return(&q->mq_freeze_depth);
if (freeze_depth == 1) {
percpu_ref_kill(&q->q_usage_counter); // Stop I/O
}

𝐖𝐡𝐚𝐭 𝐜𝐨𝐮𝐥𝐝 𝐠𝐨 𝐰𝐫𝐨𝐧𝐠?
This bug affected ALL multi-core systems running Linux 4.19+ with blk-mq enabled, including:
Intel Xeon servers with NVMe storage
AMD EPYC systems with SATA SSDs in RAID
ARM64 servers with shared storage controllers
Enterprise systems with multipath storage configurations

what happened when two CPUs tried to freeze the same I/O queue is shown in images attached.

The solution was elegantly simple but required mainline kernel changes:

// 𝐁𝐄𝐅𝐎𝐑𝐄: 𝐑𝐚𝐜𝐞-𝐩𝐫𝐨𝐧𝐞 𝐚𝐭𝐨𝐦𝐢𝐜 𝐨𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬
freeze_depth = atomic_inc_return(&q->mq_freeze_depth);
if (freeze_depth == 1) percpu_ref_kill();

// AFTER: Mutex-protected critical section
mutex_lock(&q->mq_freeze_lock);
if (++q->mq_freeze_depth == 1) {
percpu_ref_kill(&q->q_usage_counter);
}
mutex_unlock(&q->mq_freeze_lock);

𝐓𝐡𝐢𝐬 𝐫𝐚𝐜𝐞 𝐜𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧 𝐜𝐚𝐮𝐬𝐞𝐝 𝐰𝐢𝐝𝐞𝐬𝐩𝐫𝐞𝐚𝐝 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐟𝐚𝐢𝐥𝐮𝐫𝐞𝐬:
RAID arrays stuck in recovery
Journal threads unable to commit
Applications frozen during file writes
System requiring reboot

Key Lessons for System Design
1. Per-CPU Data Isn’t Always the Answer
2. Atomic Operations Have Limits
3. Critical Sections Must Be Identified

Questions for Discussion
1) How do you handle race conditions in your multi-threaded applications?
2) What debugging tools do you use for concurrency issues?
3) Have you encountered similar production issues with “atomic” operations?

🎓 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐎𝐩𝐩𝐨𝐫𝐭𝐮𝐧𝐢𝐭𝐢𝐞𝐬:
A) 𝐒𝐞𝐥𝐟-𝐏𝐚𝐜𝐞𝐝 𝐂𝐨𝐮𝐫𝐬𝐞:
𝐏𝐥𝐚𝐜𝐞𝐦𝐞𝐧𝐭 𝐬𝐮𝐩𝐩𝐨𝐫𝐭
Learn at your own pace
Structured kernel programming modules
Practical examples, bug studies like this one
Hands-on debugging experience

B) 𝐖𝐞𝐞𝐤𝐞𝐧𝐝 𝐎𝐧𝐥𝐢𝐧𝐞 𝐂𝐨𝐮𝐫𝐬𝐞 𝐟𝐨𝐫 𝐖𝐨𝐫𝐤𝐢𝐧𝐠 𝐏𝐫𝐨𝐟𝐞𝐬𝐬𝐢𝐨𝐧𝐚𝐥𝐬:
180+ Hours of comprehensive training
8 Months structured program
Flexible scheduling for working professionals

𝐌𝐨𝐝𝐮𝐥𝐞𝐬 𝐂𝐨𝐯𝐞𝐫𝐞𝐝:
System Programming
Linux kernel internals
Linux device driver development
Linux socket programming
Network device drivers, PCI, USB driver walkthrough
Linux crash analysis and Kdump
JTAG debugging