-
Notifications
You must be signed in to change notification settings - Fork 1
/
Requirements
178 lines (128 loc) · 7 KB
/
Requirements
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
A requirements document is a handy thing to have, both before and
after the fact. I had no formal one when I started, but this one is a
collection of the requirements I think exist.
1) General
1.1) OpenIPMI will support both threaded and non-threaded
applications and offer full function to both environments.
(Note that this drives the event-driven nature of the
interface).
1.2) OpenIPMI will be written in ANSI-standard C.
1.3) The main parts of the code will not depend directly on the
operating system, but will use an operating-system abstraction
layer to make the code portable.
1.4) For operations that a user initiates, the results will always
be returned if the system survives.
1.5) OpenIPMI will be fully dynamic and support changing system
configurations.
1.6) For the user, all locking will be done with callthroughs
(meaning that the user calls a function that then calls a
function the user provides, in the user-provided function the
lock will be held). This avoids forgetting to release locks.
1.7) OpenIPMI will scan the system to determine what is installed
and present it to the user.
2) Connections
2.1) The lower-level connections will be through an abstract type
with function pointers, so that different interfaces can be
plugged into the system.
2.2) The connections will be as abstract as reasonably possible, to
support LAN, serial, system iterfaces, or proprietary
interfaces.
2.3) A IPMI 1.5 LAN connection using Unix sockets and a system
interface using the OpenIPMI device driver will be provided.
2.4) For LAN connections, the connection will support multiple IP
addresses and ports for a single card with automatic
failovers, failure detection, and recovery.
2.5) OpenIPMI will support multiple MC interfaces into the same
system (primarily for fault tolerance). It will support
active/active and active/standby configurations with automatic
failovers, failure detection, and recovery.
3) User Interface
3.1) The user will be able to open multiple connections with one
library.
3.2) The user interface will be clearly split into external
interface (that are abstract enough to not depend directly on
IPMI) and internal interfaces (that are IPMI specific).
3.3) The external interface will deal only with connections,
entities, events (bot not event internals), sensors, and
controls. They will not deal with SDRs, SELs, management
controllers, IPMB addresses, event contents, or other
low-level concerns of IPMI.
3.4) All interfaces to data will be through function calls, not
through direct access to structure components.
3.5) The interface will be fully extensible, no arbitrary
limitation will be placed on any value in the interface.
3.6) When raw (unconverted) values come in, the interface will
convert them to floating-point values and give the user access
to both the raw and floating point value.
3.7) As system configuration changes, the changes will be reported
to the user as they happen.
3.8) The user will be able to query the current system
configuration through iterators.
3.9) All strings for readings and values will be avaliable to the
user.
4) Entities/Sensors/SDRs
4.1) OpenIPMI will automatically read the SDRs from a system and
create entities and sensors.
4.2) The user will be given full access to all field of the SDRs
for a sensor.
4.3) The user may add entity associations (parent/child
relationships for entities).
4.4) OpenIPMI will support writing the main SDR repository with
entity associations and with sensors that came from there.
4.5) The user will have full access to all IPMI operations for the
sensor.
5) Events
5.1) All incoming events must be delivered to the user in some
manner, so the user can delete them from the SEL.
5.2) When an event is received for a known sensor with an installed
handler, it will be delivered through that sensor's interface
with all the information converted as appropriate to the
sensor.
5.3) OpenIPMI will support multiple SEL devices in a chassis. Any
management controller that supports an SEL will be scanned.
5.4) OpenIPMI will configure the events receivers on all management
controllers as necessary.
5.5) OpenIPMI will support deletion of events from SELs
5.6) All events in the SELs before detection of the management
controller will not be delivered as sensor events (since their
information may be old) but delivered through a generic event
interface.
6) Controls
6.1) OpenIPMI will support controls for output devices.
6.2) The following controls are supported: lights (including LEDs),
relays, displays (2-d text devices), alarms (generic alerting
devices), reset (controls reset of entities), power (controls
power to an entity or power from an entity if it is a power
supply), fan speed, and identifiers (unique ids for an entity).
6.3) Some output devices may have multiple devices that cannot be
set independently (for instance, you may have two LEDs that
you send a message to set, and they cannot be set
independently, the message sets the value of both LEDs at the
same time). In these cases, a single control will control
both devices, and the control will have muliple instances.
All instances must be set together when setting the value of
the control.
6.4) Controls may be read and/or written, depending on the capabilities
of the device. The capabilities of the device will be
advertised through the API.
7) OEM plug-ins
7.1) OpenIPMI will allow plugins for handling OEM operations on
connections. The plugin will be able to handle active/standby
operations and connection IPMI address detection. It will be
given full access to the function pointers for the interface
so it can override any operations it needs to handle.
7.2) OpenIPMI will allow plugs for handling specific management
controllers. The plugin will be able to change any attributes
of the management controller it wishes, and be able to
intercepts the addition of entities, sensors, and the receipt
of events.
7.3) OEM code will be able to create entities, sensors, and
controls and handle the operations for those things so it can
simulate real ones.
7.4) Multiple OEM plugins will be supported simultaneously, so
connections and management controllers from different vendors
can be supported at the same time.
8) Other Code
8.1) OpenIPMI will include a direct command interface.
8.2) OpenIPMI will include an IPMI LAN emulator to convert a system
interface into a LAN connection.