问题
The following line printed output as 4 whereas I was expecting 0.
printk(KERN_INFO "size of spinlock_t %d\n", sizeof(spinlock_t));
I tried this on a system with single cpu. No debugging flags are enabled while building kernel like CONFIG_DEBUG_SPINLOCK or CONFIG_DEBUG_LOCK_ALLOC. According to kernel header files, it should be zero but output is not consistent with it, any guesses ?
回答1:
The best guess I have is that although you have a single CPU, the kernel is still compiled with CONFIG_SMP set.
回答2:
The sizeof a type can never be zero.
回答3:
The spinlock_t is always a structure and it contains a rawlock_t irrespective of kernel build options. SMP and kernel preemption can add extra fields to the spinlock_t, but spinlock_t is always a concrete type with a none zero size. The compiler needs the spinlock_t to resolve to a real valid C type otherwise it wouldn't compile any structure that incorporated a spinlock. If there is no preemption or SMP then its the spinlock operations that are NULL not the structure. To support a zero sized structure would be very messy, every reference would need to be via pre-processors macros so spinlock_t ends up being an int (on x86 at least), there isn't any point going for an variable whose size is less than 4 bytes because the compiler is likely to pad any variable to maintain alignment.
回答4:
From what I remember, spinlock_t is enabled only in CONFIG_SMP is set i.e it is disabled on uniprocessor machines. Therefore, you might be getting some garbage.
回答5:
This depends on your architecture. If you look at include/linux/spinlock_types_up.h, you can see that there are indeed times where it will come out to 0 size.
来源：https://stackoverflow.com/questions/1626017/why-sizeofspinlock-t-is-greater-than-zero-on-uni-processor