留言板
路过的蜗牛们，在这里留个脚印吧～
蜗窝欢迎各种言论，谈天说地、技术交流、问题求救、跳槽招聘、牢骚抱怨……哈哈。
评论：
linuxer
2015-07-28 23:11
2015-07-28 23:11
@fucker：第一个问题，如何研究的这么深入？喜欢是最大的动力，只有发自内心的喜欢才可以付出时间和精力。第二个问题，研究linux kernel当然是一个实践的活动，例如你想要优化内核中的某些操作。不过目前我们主要是阅读代码为主，动手实践较少，有机会的话申请一些开发板什么的就有实践机会了，我们一直在寻找ARM64的服务器平台，希望可以在上面有些动手机会，不过目前时机还不成熟。第三个问题，研究内核其实不太容易带来财富，如果为了财富，可以考虑一些互联网软件或者一些应用程序软件，研究内核毕竟是一个小众行为，多半是自爽吧，我们目前没有什么明确的目标，也许将来搞一些高端的内核培训，也许可以出一些书籍，目前反正都有工作，能养家糊口，这个网站就是一个纯粹技术交流的平台
Daniel Shieh
2015-07-21 17:46
2015-07-21 17:46
wowo，现在遇到一个问题，查看源码，最晚从2.6.25内核开始，内核中的sys_msgget，sys_msgsnd，sys_msgrcv，sys_msgctl几个函数的原型都找不到了，都只能在linux/syscalls.h头文件中看到声明，但是找不到函数源码？这是什么逻辑呢？而且好多地方还调用了这个函数，这是什么机制变了还是怎么啦？希望过来人明示。需要在内核态中使用消息队列，不知道有没有更好的建议。
Daniel Shieh
2015-07-21 17:48
2015-07-21 17:48
@Daniel Shieh：是2.6.25内核之后，至少2.6.30内核开始就找不到这些函数的源码了，这是怎么了？网上搜了很多，找不到答案啊。
Daniel Shieh
2015-07-22 10:00
2015-07-22 10:00
@linuxer：谢谢linuxer指点。用软件的确跳转不到，后来我自己找源码目录看的时候，也看到ipc目录下边了，有util.c和msg.c，内容大致看了下，的确是通过宏的方式了。不过我编译的内核模块，编译ok，但是在加载的时候会报错，unknown symbol in the module，查看log，就是上面说的三个函数：
unknown symbol sys_msgget
unknown symbol sys_msgsnd
unknown symbol sys_msgrcv
这可能是什么原因呢？
另外一个问题是，在内核中使用消息队列的方式是使用这些函数吗？还是有别的使用方法？
unknown symbol sys_msgget
unknown symbol sys_msgsnd
unknown symbol sys_msgrcv
这可能是什么原因呢？
另外一个问题是，在内核中使用消息队列的方式是使用这些函数吗？还是有别的使用方法？
linuxer
2015-07-22 12:19
2015-07-22 12:19
@Daniel Shieh：毫无疑问这是符号解析的问题，要解决这个问题首先要问自己这样的问题：内核的众多符号中，哪些可以被模块引用？
实际上，内核中只有用EXPORT_SYMBOL和EXPORT_SYMBOL_GPL定义的符号才能被模块引用，也就是说sys_msgget这个符号没有被内核export出来，因此，虽然内核定义了这个符号，但是对于模块而言，它是不可见的。
如何解决呢？本质上，sys_xxx是给userspace的程序使用的，内核不应该直接使用，不过也有些场景，例如在内核中操作文件。
因此，如果一定要这么做，一般而言，可以考虑使用底层的函数，不要直接调用sys_xxx函数。不过你能否告知你的场景？应该有比消息队列更好的方式
实际上，内核中只有用EXPORT_SYMBOL和EXPORT_SYMBOL_GPL定义的符号才能被模块引用，也就是说sys_msgget这个符号没有被内核export出来，因此，虽然内核定义了这个符号，但是对于模块而言，它是不可见的。
如何解决呢？本质上，sys_xxx是给userspace的程序使用的，内核不应该直接使用，不过也有些场景，例如在内核中操作文件。
因此，如果一定要这么做，一般而言，可以考虑使用底层的函数，不要直接调用sys_xxx函数。不过你能否告知你的场景？应该有比消息队列更好的方式
Daniel Shieh
2015-07-22 13:24
2015-07-22 13:24
@linuxer：使用场景：私有的无线协议栈在内核态下实现，协议栈的内部用到了消息队列。以前这部分的协议是在其他系统上以应用的方式实现的，现在要移植到linux内核态下。所以就想用系统调用的内部实现函数去替代这部分。不知道linuxer有没有更好的建议，可以用什么替代这部分？
Daniel Shieh
2015-07-23 09:39
2015-07-23 09:39
@linuxer：原来在用户空间的协议栈，在两个进程间通过消息队列传输协议数据，发送方根据消息类型通过消息队列发送数据，接收端收到数据后，进行分析，并执行相关的功能操作。你说的交互方式是这些吗？还是别的什么？
所有的逻辑都移到内核，协议部分和协议内部的分析并执行功能都移植到内核态。
内核态下还是要创建两个或者三个内核线程。
不知道这些信息够不够？谢谢linuxer耐心的帮我解决问题！
所有的逻辑都移到内核，协议部分和协议内部的分析并执行功能都移植到内核态。
内核态下还是要创建两个或者三个内核线程。
不知道这些信息够不够？谢谢linuxer耐心的帮我解决问题！
linuxer
2015-07-23 21:14
2015-07-23 21:14
@Daniel Shieh：我现在还是不是非常明白你的通讯模型，建议你还是在讨论区发一篇单独的文档和大家一起探讨。当然，这份文档需要描述清楚之前的软件架构以及目前你想调整的软件架构。要画出block diagram，描述各个block的功能以及各个block之间的接口。只有把逻辑理清楚，才能给出适合的解决方案。
Daniel Shieh
2015-08-03 11:32
2015-08-03 11:32
@linuxer：具体就是需要对收到的IP包进行私有协议的处理，传递私有协议处理的IP包给另一个线程，本来之前应用层处理用的是消息队列，现在移植到内核态，内核中应该使用什么机制去替换这种方式呢？实在是没查到相关的资料啊。
coldcl@163.com
2015-07-20 20:16
2015-07-20 20:16
根据mtk的介绍，前面那个preloader应该是他们有自己的相关芯片的一些初始化，然后才等待启动bootloader，所以我才觉得纳闷，看博主有没有碰到类似的情形
shoujixiaodao
2015-07-21 10:19
2015-07-21 10:19
@coldcl@163.com：preloader是芯片公司自己写的一个初始化流程而已。会初始化emmc，dram等。会把lk的执行bin copy到dram中，然后直接跳转过去就执行lk的代码了。不会涉及到WFI的。
coldcl@163.com
2015-07-21 11:27
2015-07-21 11:27
@shoujixiaodao：就是在preloader的时候，会进入到WFI这里，然后等待lk的唤醒...到WFI的时候是一个循环，没有跳出去
coldcl@163.com
2015-07-20 15:19
2015-07-20 15:19
博主，想请问一个关于armv8架构启动的问题，之前的v7，大概就是硬件会到一个给定的地址去load uboot，然后call kernel，但是像mtk，它有一个自己的preloader，lk（也就是bootloader），在启动之后，它先调用preloader，然后调用WFI进入standby，根据前面你的WFI的分析，后面应该是硬件去唤醒而进入到lk，这里有什么资料详细介绍是怎么触发WFI状态进入lk的吗，谢谢！！！
buyit
2015-07-13 16:15
2015-07-13 16:15
请教一个RTC设计的问题：
假设一款SOC里面没有外接的RTC，只有内部的RTC，这个内部的RTC是用timer和counter来模拟的，并不是一个真正的可以设置年月日的RTC。
SOC内部的RTC放在always on的domain里面，系统suspend的时候继续运行。
假设现在android的闹钟设置了一个5分钟之后的唤醒时间，然后全系统进入suspend，那么等闹钟时间到了，假设这个RTC有能力让系统的PMU先收到通知，然后PMU有能力唤醒AP，通常情况下AP core的resume过程是先走一遍ROM code，然后再运行kernel 的resume 过程。kernel resume的时候会把GIC 中断控制器恢复，当GIC 恢复的时候，请问RTC的中断会瞬间被触发从而调用到它的中断处理函数吗？ 假设RTC的irq pin是level-triggered并且在系统resume的过程中irq pin一直处于active状态。
1. 假设RTC的中断处理函数在系统resume的过程中不会被触发，那么很显然系统需要在RTC driver自己的resume函数里面想办法通知RTC framework: RTC到期的事件已经发生了。比如说在RTC driver的resume函数里面呼叫rtc_update_irq() ? kernel里面很难看到类似的实现。。。
2. 假设RTC的中断处理函数在系统resume的过程中被触发，那么看上去一切和系统不睡眠的时候处理RTC事件是一样的，在中断处理函数中呼叫rtc_update_irq()把事件上报给RTC framework层。
假设一款SOC里面没有外接的RTC，只有内部的RTC，这个内部的RTC是用timer和counter来模拟的，并不是一个真正的可以设置年月日的RTC。
SOC内部的RTC放在always on的domain里面，系统suspend的时候继续运行。
假设现在android的闹钟设置了一个5分钟之后的唤醒时间，然后全系统进入suspend，那么等闹钟时间到了，假设这个RTC有能力让系统的PMU先收到通知，然后PMU有能力唤醒AP，通常情况下AP core的resume过程是先走一遍ROM code，然后再运行kernel 的resume 过程。kernel resume的时候会把GIC 中断控制器恢复，当GIC 恢复的时候，请问RTC的中断会瞬间被触发从而调用到它的中断处理函数吗？ 假设RTC的irq pin是level-triggered并且在系统resume的过程中irq pin一直处于active状态。
1. 假设RTC的中断处理函数在系统resume的过程中不会被触发，那么很显然系统需要在RTC driver自己的resume函数里面想办法通知RTC framework: RTC到期的事件已经发生了。比如说在RTC driver的resume函数里面呼叫rtc_update_irq() ? kernel里面很难看到类似的实现。。。
2. 假设RTC的中断处理函数在系统resume的过程中被触发，那么看上去一切和系统不睡眠的时候处理RTC事件是一样的，在中断处理函数中呼叫rtc_update_irq()把事件上报给RTC framework层。
linuxer
2015-07-14 09:32
2015-07-14 09:32
@buyit：我先说一下我的看法，稍后再去查证。
当系统进入suspend状态的时候，为了节省GIC的大部分功能都是disable的，因为大部分的中断都不需要响应了，需要响应的的一般只剩下RTC、或者一两个GPIO的中断（多半是和power key以及charger相关），对于gic而言，其内部也可以分成中断检测HW block和wakeup功能HW block，在suspend的时候，中断检测相关的HW block被disable了，而保留了wakeup功能HW block以便检测到唤醒事件，从而wakup processor。
对于RTC hw block而言，一旦到期会立刻触发level电平通知GIC（应该是SPI类型的），在suspend状态的时候，不会导致GIC向processor报告中断事件，但是可以唤醒processor，当cpu执行resume的过程中，恢复了GIC的中断检测HW block的功能之后，GIC立刻可以检测到RTC的电平事件（没有clear interrupt，这个level 电平可以保持住），从而触发一个中断。
当系统进入suspend状态的时候，为了节省GIC的大部分功能都是disable的，因为大部分的中断都不需要响应了，需要响应的的一般只剩下RTC、或者一两个GPIO的中断（多半是和power key以及charger相关），对于gic而言，其内部也可以分成中断检测HW block和wakeup功能HW block，在suspend的时候，中断检测相关的HW block被disable了，而保留了wakeup功能HW block以便检测到唤醒事件，从而wakup processor。
对于RTC hw block而言，一旦到期会立刻触发level电平通知GIC（应该是SPI类型的），在suspend状态的时候，不会导致GIC向processor报告中断事件，但是可以唤醒processor，当cpu执行resume的过程中，恢复了GIC的中断检测HW block的功能之后，GIC立刻可以检测到RTC的电平事件（没有clear interrupt，这个level 电平可以保持住），从而触发一个中断。
buyit
2015-07-14 10:14
2015-07-14 10:14
@linuxer：我之前接触的soc里面，GIC在system suspend的时候会掉电，suspend之后会用系统的一个独立的PMU来接管唤醒的中断源。假设RTC可以触发MPU，MPU再唤醒AP，然后AP经过了ROM code之后回到了resume的流程，那么在resume的早期中有一步是去重新初始化GIC的，RTC的中断理论上来说在这一步会被恢复，于是应该会在之后的某一个时间点被触发。
不过我有另外一个问题，是对android的alarm system的： 假设RTC的irq没有连接到GIC，但是连接到了PMU，那么当RTC里面设置的闹钟时间到了之后，系统是可以从suspend状态被唤醒的，AP也可以走进resume的过程，只是RTC的irq在AP也就是kernel这边不存在，那么这种情况下android的闹钟应用是否还能正常判断出来自己设置的闹钟到期了？
不过我有另外一个问题，是对android的alarm system的： 假设RTC的irq没有连接到GIC，但是连接到了PMU，那么当RTC里面设置的闹钟时间到了之后，系统是可以从suspend状态被唤醒的，AP也可以走进resume的过程，只是RTC的irq在AP也就是kernel这边不存在，那么这种情况下android的闹钟应用是否还能正常判断出来自己设置的闹钟到期了？
buyit
2015-07-13 11:04
2015-07-13 11:04
请教各位：
我现在用的一个soc有个RTC，它的中断类型是level的，当它产生中断之后，我在中断下半部去写rtc的一个寄存器去clear这个level-triggered irq，但是由于bus和时钟同步的原因，这个写的动作比较慢，所以当我从下半部的irq handler里面返回的时候并不能保证rtc到gic的中断信号已经清除了，所以有可能会造成level irq的中断仍然没有被清除，这样系统就有可能会不停进入这个level irq。 请问这种情况下有什么好办法吗？ 我看到pxa的平台在处理mmc插拔的时候使用了如下方法：
1. 中断产生
2. disable_irq，
3. 启动一个timer，设置一个经验值作为到期时间，比如1s
4. 退出中断处理函数，本次中断处理完成，但是这个mmc irq处于disable状态。
5, timer到期之后，在timer handler里面polling mmc的一个寄存器，确定irq状态清除之后，enable_irq
这种方式消耗cpu是最少的，但是我很难找到其它平台使用类似的代码，因此我想是不是还有更好的解决方式？
我现在用的一个soc有个RTC，它的中断类型是level的，当它产生中断之后，我在中断下半部去写rtc的一个寄存器去clear这个level-triggered irq，但是由于bus和时钟同步的原因，这个写的动作比较慢，所以当我从下半部的irq handler里面返回的时候并不能保证rtc到gic的中断信号已经清除了，所以有可能会造成level irq的中断仍然没有被清除，这样系统就有可能会不停进入这个level irq。 请问这种情况下有什么好办法吗？ 我看到pxa的平台在处理mmc插拔的时候使用了如下方法：
1. 中断产生
2. disable_irq，
3. 启动一个timer，设置一个经验值作为到期时间，比如1s
4. 退出中断处理函数，本次中断处理完成，但是这个mmc irq处于disable状态。
5, timer到期之后，在timer handler里面polling mmc的一个寄存器，确定irq状态清除之后，enable_irq
这种方式消耗cpu是最少的，但是我很难找到其它平台使用类似的代码，因此我想是不是还有更好的解决方式？
buyit
2015-07-14 10:03
2015-07-14 10:03
@linuxer：是SOC上的RTC，不过芯片设计人员给出了这样子的解释，由于CPU和RTC模块的clock差太多，CPU在1ghz，RTC在32KHz，所以RTC在收到寄存器写入之后需要很久(相对于cpu的cycle来说很久，相对于rtc自己的cycle来说其实不久)才能拉irq pin。
linuxer
2015-07-14 12:37
2015-07-14 12:37
@buyit：对level类型的中断而言，基本上在interrupt handler（top half）中需要完成clear interrupt的动作，否则，在执行完成interrupt handler之后会unmask该irq（参考handle_level_irq函数），如果没能清中断，那么中断会立刻再次进入的。
如果外设和CPU是通过慢速总线连接，那么这个clear interrupt的动作的确会比较慢，例如通过I2C接口访问寄存器来清除外设的中断。针对这种情况，基本上linux kernel中可以使用threaded interrupt handler，并且将flag设定为oneshot。当然，你这个场景的总线其实并不慢，慢的是外设的clock。不过，你说的场景有点怪，我倒是置疑硬件的设计。本质上，软件写寄存器来clear rtc interrupt，那么其irq signal应该立刻deasserted，也就是说寄存器和irq signal应该是同步的，否则，难道硬件人员还需要提供一个状态寄存器来说明rtc irq signal的状态？这太奇怪了。另外，对于RTC hw block，其包括两个clock domain，一个慢速的、驱动RTC自身功能运作的那个32768 clock，另外一个clock domain是来自和CPU 连接的bus上的clock，我认为清除硬件的中断信号这个HW功能不应该位于slow clock上。可能硬件设计有困难吧，anyway，你说的这种情况，除了在rtc interrupt handler中disable该irq，我还真是想不出其他方法了。
如果外设和CPU是通过慢速总线连接，那么这个clear interrupt的动作的确会比较慢，例如通过I2C接口访问寄存器来清除外设的中断。针对这种情况，基本上linux kernel中可以使用threaded interrupt handler，并且将flag设定为oneshot。当然，你这个场景的总线其实并不慢，慢的是外设的clock。不过，你说的场景有点怪，我倒是置疑硬件的设计。本质上，软件写寄存器来clear rtc interrupt，那么其irq signal应该立刻deasserted，也就是说寄存器和irq signal应该是同步的，否则，难道硬件人员还需要提供一个状态寄存器来说明rtc irq signal的状态？这太奇怪了。另外，对于RTC hw block，其包括两个clock domain，一个慢速的、驱动RTC自身功能运作的那个32768 clock，另外一个clock domain是来自和CPU 连接的bus上的clock，我认为清除硬件的中断信号这个HW功能不应该位于slow clock上。可能硬件设计有困难吧，anyway，你说的这种情况，除了在rtc interrupt handler中disable该irq，我还真是想不出其他方法了。
功能
最新评论
- 安庆
@markened-frank：是的，但是它前面是tlbi啊 - bngvcztboj
劲舞团问道密传一条龙www.43vb.com13258761... - small
wowo，你好 我遇见有一个唤醒锁一直无法关闭，我想强制关... - 狗子
@王：老铁 休息就别卷了 受不了 - markened-frank
我记得DSB的语义是等待本核的前面的操作完成，并不能等待其他... - bsp
@icy_river：bsp 2023-02-01 13:...
文章分类
随机文章
文章存档
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2015-07-28 19:09
大神们好~！
非常感谢你们的精彩分享，文章写的很美，很让人振奋。非常感叹你们怎么可以知道那么多呢。。。。
因为我是手机行业，虽然也做的是驱动，但是感觉做的很肤浅，如果仅仅完成工作，也行不需要这么深的知识，但是我真的很佩服你们，因为我觉得能把知识分享给别人是一种美。希望自己也有一天可以在这里写点干货。所以有点疑惑想请教下。
①工作需要，可能不需要这么深的知识，那么如何才能研究的这么深入呢？
②如果仅仅是看代码，总觉得有点肤浅，总觉得需要用实验来验证下，但是这样的话，感觉又太慢了，你们是怎么平衡的呢？
③如果从知识转换为财富的角度，你们觉的这样研究下去，将来的出路是什么呢？因为我总又种预感，终端将来只能是一个为云服务的简单入口，起到的作用和价值会越来越弱。
也行我的思路有些乱，，，我现在大概这些问题，以后再请教！
thanks