sysrepo

项目使用yang文件对数据进行管理，在开发阶段，yang文件定义经常变化，许多是不兼容的变化，毕竟在开发阶段许多数据都还没最终确定下来，随着开发的进展需求也渐渐的迭代，免不了出现不兼容的情况。原先使用

# 系统时间更改导致的问题 修改系统时间是一个不是常用的功能，但是又是很必须的。看起来很简单的系统时间的修改，也出了好几个问题。

刚开始定位问题的时候，如果python程序的进程挂住了或者是coredump了，使用gdb进行调试，只能通过bt看到c函数的调用栈，没有办法看到python对应的代码，问题的定位比较困难。

最近有业务开发反馈他们在执行一个命令的时候，在命令行分页停留的时候，会导致他们数据面的程序挂住。分析了一下原因

这是周谈第一篇 情况是这样的，项目使用命令行进入，如果在未连接上netconf服务端的时候，马上敲入命令，会导致那个netconf连接不正常。好在这是一个必现的问

前言 最近跟同事联调的时候，遇到了一个问题。我这边使用sysrepo实现了一个更改系统时间的功能的rpc，然后调用方每次调用的时候，如果设置的是将来的某个时刻，总是返回超时，设置当前时间以前的某个时刻

前言 sysrepo对资源的保护自己实现了一个读写锁， 支持多个线程同时读，只有一个线程在写的保护。使用的是互斥量加条件量来实现的。读写互斥使用一个变量控制。结构如下(基于1.4.87版本，新版本变了

前言 几个月前了吧，团队有人测试了一下通过netconf给list类型的节点添加2w条表项，发现随着表项数目的增加，后面创建新表项的时间几乎呈一个线性的增长。到最后，每增加一个配置，大概就要耗时8s左

背景 sysrepo是基于共享内存的数据库，实际共享内存的外在体现是一个共享的文件。对这个共享文件的访问控制又是通过文件锁的方式来实现的。因为sysrepo只是一个库而已，会被多个进程链接，共享内存文

插件顾名思义就是通过宿主程序提供的机制，影响宿主程序而实现特定功能的一种程序。 sysrepo数据库的一个重要的功能是在数据变更的时候，通过共享内存文件保存变更的内容，然后通过变更内容的模块找到相关路

模块和数据节点的树结构 sysrepo对yang文件节点数据及模块的解析是一个有层次的关系结构： 顶级节点没有parent=NULL， 兄弟节点的parent是相同的。 兄弟节点间是一个特殊的双向链表

上一篇讲了sysrepo使用管道做事件通知，至于处理数据则通过共享内存文件来保存。sysrepo号称是共享内存型的数据库，主要就是由于其数据都是通过共享内存文件保存的。 创建的共享内存文件，默认都是在

前言 由于项目需要，安排了一个月左右的时间研究一下开源代码sysrepo这个共享内存型的数据库，后面得根据需要实现一些定制的需求,还有性能提升，数据是yang模型的数据。整体代码量大概3w行，每天刷个