开发者

Why sizeof(spinlock_t) is greater than zero on uni-processor?

开发者 https://www.devze.com 2022-12-09 23:55 出处:网络
The following line printed output as 4 wh开发者_StackOverflow社区ereas I was expecting 0. printk(KERN_INFO \"size of spinlock_t%d\\n\", sizeof(spinlock_t));

The following line printed output as 4 wh开发者_StackOverflow社区ereas 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 ?


The best guess I have is that although you have a single CPU, the kernel is still compiled with CONFIG_SMP set.


The sizeof a type can never be zero.


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.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号