蜗窝科技

还有就是 类似这种链表操作比较多的。 static int sysfs_readdir(struct file * filp, void * dirent, filldir_t filldir) 366{ ....................................... 370 struct list_head *p, *q = &cursor->s_sibling; 371 ino_t ino; 372 int i = filp->f_pos; 373 374 .........................................*/ 389 default: 390 if (filp->f_pos == 2) { 391 list_del(q); 392 list_add(q, &parent_sd->s_children); 393 } 394 for (p=q->next; p!= &parent_sd->s_children; p=p->next) { 395 struct sysfs_dirent *next; 396 const char * name; 397 int len; 398 399 next = list_entry(p, struct sysfs_dirent, 400 s_sibling); 401 if (!next->s_element) 402 continue; 403 404 name = sysfs_get_name(next); 405 len = strlen(name); 406 if (next->s_dentry) 407 ino = next->s_dentry->d_inode->i_ino; 408 else 409 ino = iunique(sysfs_sb, 2); 410 411 if (filldir(dirent, name, len, filp->f_pos, ino, 412 dt_type(next)) < 0) 413 return 0; 414 415 list_del(q); 416 list_add(q, p); 417 p = q; 418 filp->f_pos++; 419 } 420 } 421 return 0; 422} ===== 我读起来迷迷糊糊的

请教大奖一个基础的C语言的问题或者说对指针的理解吧 我在2.6.10中看到 #define subsys_set_kset(obj,_subsys) (obj)->subsys.kset.kobj.kset = &(_subsys).kset 还有down_write(&kobj->kset->subsys->rwsem); 怎么理解这么多的->或者. --- 什么时候该用 ‘ .’ 什么时候用->

Hi linuxer @linuxer 你之前的文章关于work同步的解释如下： =>挂入到multi thread或者说per cpu workqueue上的指定的work，其callback是不会在一个cpu上并发执行（也就是说在多个cpu上可以并发执行） 此篇文中有这样一段话：“不是当前选定的那个pool wq对应的worker pool就适合该work，因为有时候该work可能正在其他的worker thread上执行中，在这种情况下，为了确保work的callback function不会重入，该work最好还是挂在那个worker thread pool上” =>这一段的意思是： 1. 对于per cpu来讲保证同一个work不能在同一个cpu对应的worker pool里的多个worker thread里面同时执行，但可以在不同的cpu 的worker pool里的worker thread执行。 2. 对于UNBOUND的情况，可以将属于同一个node id的若干个个cpu视作一个逻辑cpu，保证同一个逻辑cpu里面不会出现多个worker thread执行一个相同的work，不同的node id（即不同的逻辑cpu）里面的worker thread是可以同时执行一个相同的work的。 我这样理解是正确的吗？如有偏差请指正，谢谢！

不错，不错，值得学习

@wowo：非常感谢

请问博主的这些文章引用的内核源码的版本是多少？是基于一个内核版本写的还是不同，是否可以说明方便我们阅读时参考对应，谢谢。

Hi linuxer, @linuxer,您好： 看了您的文章收获非常大，现有几个问题罗列出来希望指点一二，谢谢。 1. 本文中提到的这个流程图：关中断：mask and ack interrupt controller-------->ack NIC-------->copy FIFO to ram------>raise softirq------>unmask interrupt controller =>最后一步unmask interrupt controller 这个是在中断处理程序执行完由硬件操作寄存器来进行操作的吗？ irq_exit rcu_irq_exit local_irq_save(flags); local_irq_restore(flags); 既然流程第一步已经进行了执行了mask，为什么rcu_irq_exit 还会进行关闭中断的操作啊？硬中断处理中关闭中断的操作是硬件实现的？ 2. 关于softirq的执行场景，目前我的理解： 1)是在中断上下文： irq_exit if (!in_interrupt() && local_softirq_pending()) //有pending softirq且没有disable_bh invoke_softirq(); 2)一个使用local_bh_disable和local_bh_enable来保护临界区的task，在local_bh_enable退出临界区时如有pending softirq则在该task的进程上下文执行。 3)由wakeup_softirqd 唤醒，在softirqd的进程上下文中执行。 综上所述的情况，我们说softirq和tasklet运行在中断上下文是不是有些不恰当？ 3. 关于下面这段代码有个疑问想请教一下： do_softirq(void) local_irq_save(flags); //save本地中断状态，关中断 ----- a pending = local_softirq_pending(); __do_softirq(); pending = local_softirq_pending();//获取 softirq pending 状态 ----- m set_softirq_pending(0); //清除pending标志 local_irq_enable //开中断 ----- b h->action(h); ----- c local_irq_disable //关中断 ----- d pending = local_softirq_pending();//重新获取 softirq pending 状态 ----- n if (pending) { if (time_before(jiffies, end) && !need_resched() && --max_restart) goto restart; wakeup_softirqd(); } local_irq_restore(flags); //restore本地中断状态，开中断 ----- e 在c过程中又发生了中断打断了正在执行的softirq handler，又raise了softirq，那么中断结束又返回到被打断的softirq handler，继续执行m处获取的pending softirq，执行完毕后在n处获取新的 pending softirq 跳转到restart那里重新处理，我的描述正确吗？ 谢谢！

@wowo：非常感谢！ :))

@老陆：我觉得，你之所以觉得理解困难，是因为你把协议的上下层次搅在一起去理解了。 协议的根本点就是，纵向的每个层次互相独立，都可以单独理解。 回到我们这个话题上，先明确一点：从LL看，BLE怎么才算处于连接状态？ 答案是，连接双方的LL能正确的按照节拍收发数据，如果miss几次，就可能超时断开了。 所以，无论上层协议有没有实际的数据，LL都要维持这个M->S/S->M的节拍。 因此，如果上层协议有数据传输，LL很乐意的帮它们传输。如果没有怎么办？LL的数据节拍还是要维持，只不过不需要携带有效的用户数据而已（空包）。 “给我感觉连接事件是在LL层产生的”这句表述还是有问题，连接事件不是“产生”的，是连接建立之后的一个固有属性。 连接断开的话，每个BLE设备都会汇报一个断开原因的event，先大致确认一下。 至于断开的原因，很多，总结出来就是M主动断，S主动断，连接超时（距离过大，信号质量不好，某一个设备的LL无法处理了，等等）。

@wowo：1. 打个比方，我现在有个GATT Service，其有一个characteristic的Properties为Notify，然后周期性地更新它，那么我感觉在LL，应该只有S->M的包。可上面又说了，在每个连接事件都有M->S和S->M，挺难理解的，是不是在这种情况下，M->S是空包？ 2. 您之前说的，连接后，就算没有数据传输，也会在每个连接事件中传输空数据包，给我感觉连接事件是在LL层产生的..... 可能是我理解能力太差了 :(( 楼主对我遇到的，没有应用数据传输，连接正常，有数据传输后反而连接会断开的问题，有没有什么建议？ 谢谢了！