LoGin
这个restart是内核内部的一个错误码，用户层是永远不应该获得到它。但是我们却把它返回到用户层，可能是内核在这一块的实现有问题。 这里应该是先处理完信号，然后再次由内核自己进入刚才的那个上下文那里去。整个过程不需要用户程序去参与。
> > 这个restart是内核内部的一个错误码，用户层是永远不应该获得到它。但是我们却把它返回到用户层，可能是内核在这一块的实现有问题。 > > 这里应该是先处理完信号，然后再次由内核自己进入刚才的那个上下文那里去。整个过程不需要用户程序去参与。 > > 可能是放返回值的寄存器保存和恢复有点问题 不是的，他是会检测到有信号要处理，就会退出系统调用，才能进入信号处理函数。但是信号处理完之后，没有内核自身重新进入系统调用。貌似这个是需要由内核自己完成。
这个我目前想到的情况有以下两种： 1. 如果当前进程处理信号的结果是要进入用户态的信号处理函数，那么在那个sigreturn的系统调用那里啊，在还原原本的现场之后重新执行系统调用。 2. 如果当前进程处理信号的结果是向父进程发送信号，也就是说他不用再进入用户态的处理函数的话，那么，在信号处理结束后，重新执行一遍系统调用处理程序就行了
跟这个 https://github.com/DragonOS-Community/DragonOS/issues/684 有点类似，都是信号处理结束后未能再次重启调用。
r? @Chiichen 麻烦看看这个
@xiaolin2004 我看到上游thingbuf发布了新版本，并且标记那个issue为completed了，这两天你方便测试一下吗
嗯，这个有同学在做哈哈
目前正由@TTaq 开发
r? @Chiichen 貌似这类问题跟当时引入动态加载（不是动态链接）的那个pr有点关系。
非常神奇的，vision five2的`/sys/class/rtc`目录下没有任何内容，但是我开发板也没有链接网络。 看了文档之后猜测实时时钟是从rtc-oscillator里面来的。 