IPMI从驱动到应用(中篇 )

简介:


IPMI从驱动到应用(中篇)


上篇我们讲到了IPMI底层硬件连接和内核里驱动的实现,这样就为应用程序开发者提供了便利,用户只需要利用标准的设备文件打开操作、调用享用的IOCTL就可以向BMC发送请求或者读取响应结果。


应用程序开发工程师除了使用这种方法外,还可以利用现有开源的封装了上述操作的代码。目前开源的IPMI代码主要有ipmitoolOpenIPMI。感兴趣的读者可以用git clone git://git.code.sf.net/p/ipmitool/source ipmitool-source下载ipmitool的源代码,可以用git clone git://git.code.sf.net/p/openipmi/code openipmi-code下载OpenIPMI代码。前者会编译出一个个符合IPMI规范的用户态的命令”ipmitoo”,它能够用来向BMC查询系统主板、风扇、电源、温度等状态信息。支持了很多参数,使用灵活,短小精悍。还可以用它的raw command格式发送不同厂家自己定义实现的OEM命令,能够满足各种常用的场景。美中不足的是,它对OEM的系统事件日志的解析需要根据vendor定义的格式修改代码。此外,由于下面的几点原因,BMC需要实现System management software(SMS)来定期检测系统状态:

  • 过热或长期处于偏热的状态会减少硅上芯片的寿命;

  • 随着电容老化,系统会慢慢出错;

  • 风扇会随着使用年限慢慢出错;

  • 在器件出错前,应该采取预防性的措施防止出现灾难性的后果。

但是IPMI没有提供一套便于实现SMS的框架和接口,针对这个不足,OpenIPMI迎运而生。


OpenIPMI基于事件驱动模型,提供了回调和超时机制,封装了锁、多线程库和内存管理,隐藏了操作系统的区别,屏蔽了SMI(System Managment Interface)Lan接口、IPMB接口的使用差异,用户可以直接使用OpenIPMI库进行二次开发,专注于和BMC IPMI相关业务的模块和实现,不用再额外考虑太多锁、同步和事件驱动模型本身的设计,极大地提高了开发效率。OpenIPM中涉及到下面六个基本概念,理解这些概念是快速把握OpenIPMI的关键:

  • connection:  凡是BMC和外部模块连接的方式都可以叫作connection,比如smi/lan/IPMB

  • domain:   可以自动探测到的SDR/Sensors/FRU等的实体的集合;

  • Entities: 凡是能被检控的器件或者模块都叫做entity,可分为非固定位置的entity(比如机箱内的PSU/ambient)和固定位置的entity

  • sensors: 用来监控系统上的某个对象,可分为threshod sensor and discrete sensor,前者是连续值,通过跟与设定的阈值的比较来触发SEL或者设置起特殊的状态位;而后者是离散值,不同的值表示不同的状态,以电源为例子,它表示上电、掉电、出错、AC lost等状态;

  • Controls:包括点灯、中继、显示、报警、重启动、风扇转速、one-shot-reset,one-shot-outputs、标识符;

  • Events:系统事件通常由跟sensor/control/entity相连的事件回调函数处理。回调函数需要返回一个值,来标志该handler是否已经处理那个Event.


OpenIPMIPMI驱动的简要模块如下图所示: 

wKiom1X6r0mBa0zNAAGQx2xHWg8051.jpg


那么该怎样写一个基于OpenIPMI的程序?下面基于sample/dump_sensor.c进行分析,主要步骤如下:

1. allocate OS handler

Os handler 屏蔽了操作系统的差异,向OpenIPMI Library提供了统一的服务,以便实现事件驱动模型。这些服务包括:回调接口,超时计数器,条件变量(OpenIPMI不用)和锁和线程机制。

2.更新handler的相关设置,比如日志记录等;

3.初始化IPMI library. ipmi_init(os hanlder) 包括下面的步骤:

  • 建立起内存分配器

  • 定义了定制化的处理:在ipmi event/command/responce或者错误出现的时候的响应函数;

  • 建立连接:定义了地址设置、改变连接状态、发送命令、添加和删除事件处理函数、发送响应、处理器响应出错等连接时可能出现的问题

  • 初始化通信接口:注册smilan这两个接口

  • 初始化domaindomain是一个具有不同ID但是互联到management controler的集合,为什么需要引进这个domain? 需要它来区别多mc系统中某个mc以及与之连接的各个entities (_ipmi_domain_init),它初始化mc_oem_handlersdomain_change_handlersdomains_listoem_handlers

  • 初始化mc:OpenIPMI基于状态机来描述INACTIVE/ACTIVE/CLEAN UPmc的状态

  • 初始化远程console;

  • 指定payload的加密算法:AES-CBC-128/ xRC4-128 /xRC4-40

  • 指定RMCP认证算法:HMAC-SHA1 integrity

  • 注册md5算法

  • 初始化FRU解码句柄

  • 注册FRU相关读写函数,读取FRU 原始数据

  • 初始化payload size for SOL

  • 根据manufactory_ID,Product_ID来初始化一些OEMMC, 这些型号包括:force_conn, motorala_mxp,intel,kontron,atca

  • 运行OEM Test

4.解析参数:ipmi_parse_args2: 接收用户的输入

5.建立起来连接:根据输入的参数建立起相应的连接

6. open domain并注册connection建立起来后执行的操作;

7.调用perform_one_op()来实现指定的操作。


开发者可以基于上面和sample目录下其他的例子来实现自己的功能,本人就基于demo程序实现了一个跟目标系统的库,使用起来非常方便。想知道我是怎么实现的吗?OpenIPMI的库和回调函数是怎么回事?小编还会接着和大家分析,请持续关注。















本文转自存储之厨51CTO博客,原文链接:http://blog.51cto.com/xiamachao/1695818 ,如需转载请自行联系原作者



相关文章
Linux ALSA驱动之二:声卡的创建流程 下
Linux ALSA驱动之二:声卡的创建流程 下
Linux ALSA驱动之二:声卡的创建流程 下
|
10月前
|
Ubuntu Linux 开发者
韦东山Linux驱动入门实验班(2)hello驱动---驱动层与应用层通讯,以及自动产生设备节点
韦东山Linux驱动入门实验班(2)hello驱动---驱动层与应用层通讯,以及自动产生设备节点
106 0
|
11月前
|
Linux API
Linux驱动分析之SPI驱动架构
Linux驱动分析之SPI驱动架构
|
11月前
|
缓存 Linux API
Linux驱动分析之Uart驱动架构
UART设备驱动可以使用tty驱动的框架来实现,但是因为串口之间有共性,所以Linux在tty接口上封装了一层(serial core)。后面我们再拿一篇文章来解释tty驱动,tty其实就是各种终端设备,串口其实也是终端设备。
Linux驱动分析之Uart驱动架构
|
12月前
|
Linux 芯片
Linux驱动分析之MMC Host驱动
前面聊了MMC子系统《[Linux驱动分析之MMC子系统框架》,接下来我们拿个MMC Host驱动分析一下,来看看大致流程是怎样的。文章很长,代码很多,看个流程即可。
|
Linux 芯片 内存技术
Linux ALSA驱动之二:声卡的创建流程 上
Linux ALSA驱动之二:声卡的创建流程 上
|
编解码 Linux 索引
Linux ALSA驱动之四:Control设备创建流程源码分析(5.18)下
Linux ALSA驱动之四:Control设备创建流程源码分析(5.18)下
Linux ALSA驱动之四:Control设备创建流程源码分析(5.18)下
|
编解码 Linux API
Linux ALSA驱动之四:Control设备创建流程源码分析(5.18)上
Linux ALSA驱动之四:Control设备创建流程源码分析(5.18)上
|
Linux
嵌入式linux/鸿蒙开发板(IMX6ULL)开发(二十九)驱动进化之路:总线设备驱动模型
嵌入式linux/鸿蒙开发板(IMX6ULL)开发(二十九)驱动进化之路:总线设备驱动模型
124 0
嵌入式linux/鸿蒙开发板(IMX6ULL)开发(二十九)驱动进化之路:总线设备驱动模型
|
开发工具 git
UART子系统(十三)编写虚拟UART驱动程序_框架
UART子系统(十三)编写虚拟UART驱动程序_框架
111 0
UART子系统(十三)编写虚拟UART驱动程序_框架