蜗窝科技

Hi Woniu, 好文章! 不知你是否认识我那只"小蜗"? 叶子:)

@linuxer：你说的这种原子变量的情况我也设想过，只要精度不要求，确实没关系。 我只是看到内核中也有把per cpu变量用到了结构体中，这样就有可能出现结构体部分被修改的情况。 不过如你所说，对于这种情况，如果意识到会出现竞争问题就不应该使用per cpu变量了吧……

@linuxer：嗯，这样理解的话也解决了我另一个疑惑（那个size怎么想也不应该是0的...）。 那么计算的结果还是应该是64。 但是我了解到的结构体是这样的： typedef struct _IMAGE_DOS_HEADER {      // DOS .EXE header       WORD   e_magic;                     // Magic number       WORD   e_cblp;                      // Bytes on last page of file       WORD   e_cp;                        // Pages in file       WORD   e_crlc;                      // Relocations       WORD   e_cparhdr;                   // Size of header in paragraphs       WORD   e_minalloc;                  // Minimum extra paragraphs needed       WORD   e_maxalloc;                  // Maximum extra paragraphs needed       WORD   e_ss;                        // Initial (relative) SS value       WORD   e_sp;                        // Initial SP value       WORD   e_csum;                      // Checksum       WORD   e_ip;                        // Initial IP value       WORD   e_cs;                        // Initial (relative) CS value       WORD   e_lfarlc;                    // File address of relocation table       WORD   e_ovno;                      // Overlay number       WORD   e_res[4];                    // Reserved words       WORD   e_oemid;                     // OEM identifier (for e_oeminfo)       WORD   e_oeminfo;                   // OEM information; e_oemid specific       WORD   e_res2[10];                  // Reserved words       LONG   e_lfanew;                    // File address of new exe header  //PE头的偏移地址   } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;   其中是18个word类型即18*2=36字节；加上最后的long4字节，只有40字节。 既然这里是伪装成PE格式的，大小对不上，这个不应该的吧？

@speedan：其实这个问题仍然是一个基本的临界区保护的问题，per cpu变量并不会让临界区的保护更复杂，只不过是把数据访问分散到各个cpu上而已。 我们来举一个实际的例子好了：有一个per cpu变量A，该变量表示某个事件的count，该变量不会在中断上下文中访问，只会在进程上下文访问。访问的场景有两个： 1、各个cpu上的写进程会对A累加操作，记录各个cpu上事件发生的次数 2、读进程遍历全部cpu，对各个cpu上的A累加，得到一个globa count值 在这样的数据访问情况下，读进程需要锁保护吗？如果没有锁保护，那么有可能写进程会插入，但是这又有什么关系？累加后的那个globa count值有那么高的精度要求吗？ 因此，结论是： 遍历per-cpu变量时需不需要保护，用什么锁机制保护是和per cpu变量的临界区数据访问情况相关的，不同的情况需要不同的分析。

@Sky：这篇文章就是一个例子啊： [8] 和本文对应的patch文件，https://github.com/wowotechX/linux/commit/d072d177c9a88e57eb7c5f18c424b96f0ce6d2d5 你可以自己先试试，有具体问题的话再提出来讨论。 上层open就行了。

版主，请问platform的设备层要怎么写，有例子吗？ uart_ops 结构体中的函数什么时候会被调用？ 上层的用户程序如何操作serial 这个设备？是以open（）的方式吗？还是别的。

@linuxer：你说得对，我理解得不够本质，赞！！！

@linuxer：不好意思，我之前描述的问题不准确，修改如下： 我的理解，使用per-cpu变量的前提是每个CPU只能访问此变量对应当前CPU的部分，这样就不存在多个CPU并发访问的问题。 但对于需要遍历per-cpu变量的场景，意味着在当前CPU需要访问其他所有CPU对应的部分，这样使用per-cpu变量的前提就不再成立，此时似乎陷入了自我矛盾之中，应该怎么处理？ 我看内核的代码在这种情况下好像没有做过多的保护，所以挺奇怪的。 // 下边的代码是我设想的一个遍历的例子 int i, curcpu, sum; static DEFINE_PER_CPU(int, arr) = {0}; for_each_possible_cpu(i) { // 遍历per-cpu变量时怎么处理多CPU并发访问的问题？ sum += per_cpu(arr, i); per_cpu(arr, i)++; }

@蓝漪：类型当然不会变，.quad代表的就是8个字节的数据。 我帮你整理一下反汇编的结果你就明白了。 fffffc000080000 <_text>: ffffffc000080000: 91005a4d add x13, x18, #0x16 ffffffc000080004: 140003ff b ffffffc000081000 <stext> －－－－－－－－－－对应－－－－－－－－－－－－－－－ efi_head: add x13, x18, #0x16 b stext ffffffc000080008: 00080000 .word 0x00080000 ffffffc00008000c: 00000000 .word 0x00000000 －－－－－－－－－－对应－－－－－－－－－－－－－－－ .quad _kernel_offset_le

@speedan：你这是什么代码？你能不能描述一下临界区中的数据访问情况是怎样的？