虽然理解每一个(或许不是),但看起来我远远不了解两者之间的实际差异.
根据我的理解,BSP是一个驱动程序和配置设置包,允许内核映像启动板(并且是其中的一部分).单个设备驱动程序在特定组件(HW)上运行,一侧与核心内核连接,另一侧与设备本身连接.
看看Linux内核,我不清楚BSP角色的起源和设备驱动程序角色的结束位置.具体来说,我习惯于每个图像每个板看到一个BSP,但是,通用Linux内核可以加载到具有相同图像的任何架构系列(很明显,对于不同的系列,有不同的图像:x86,amd64,arm, etc ...),其中特定的板和外围设备驱动程序是从initrd按需加载的.
常见的Linux内核发行版是否有BSP？或者BSP是否与特殊案例板相关？
这种行为在其他内核上是否相似？VxWorks的？
最后一个,合并不同的BSP/s以生成适合不同电路板的单个图像是很常见的吗？
最近,我已经深入研究了原子读写的Linux内核实现,并提出了一些问题.
首先是ia64架构的相关代码:
typedef struct {
int counter;
} atomic_t;
#define atomic_read(v) (*(volatile int *)&(v)->counter)
#define atomic64_read(v) (*(volatile long *)&(v)->counter)
#define atomic_set(v,i) (((v)->counter) = (i))
#define atomic64_set(v,i) (((v)->counter) = (i))
对于读取和写入操作,似乎采用直接方法来读取或写入变量.除非在某处有另一个技巧,否则我不明白这个操作在汇编域中是否具有原子性的保证.我想一个明显的答案是,这样的操作转换为一个程序集操作码,但即便如此,在考虑不同的内存缓存级别(或其他优化)时,如何保证？
在读取宏上,volatile类型用于转换技巧.任何人都知道这会如何影响这里的原子性？(注意,它不用于写操作)
我对以下问题感到困惑:如何保持"静态"标签的优势,但仍然能够在现场调试生产代码？
一旦发生意外行为发生在客户站点,并且仅在那里发生.在许多情况下,可以选择执行调试可以节省大量精力并提供非常快速的响应.这样的调试通常涉及检查函数行为,这使我们进入"静态"定义.
无法从调试shell调试静态函数,例如放置断点或执行它.另一方面,将所有函数定义为public会导致代码结构和优化悲伤.
我知道有一些选项,比如编译至少两个不同的版本,一个是静态的,一个是没有,但是这很适合自动化测试,而不是最终的生产版本.
我们会从您这里获得一些见解,主要是关于您如何解决(如果有的话)这种困境.或者将问题改为:" 什么更重要？ "
这里对C中"静态"的讨论很好.