1 |
3 |
xianfeng |
Notes on Management Module
|
2 |
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
3 |
|
|
|
4 |
|
|
Overview:
|
5 |
|
|
--------
|
6 |
|
|
|
7 |
|
|
Different classes of controllers from LSI Logic accept and respond to the
|
8 |
|
|
user applications in a similar way. They understand the same firmware control
|
9 |
|
|
commands. Furthermore, the applications also can treat different classes of
|
10 |
|
|
the controllers uniformly. Hence it is logical to have a single module that
|
11 |
|
|
interfaces with the applications on one side and all the low level drivers
|
12 |
|
|
on the other.
|
13 |
|
|
|
14 |
|
|
The advantages, though obvious, are listed for completeness:
|
15 |
|
|
|
16 |
|
|
i. Avoid duplicate code from the low level drivers.
|
17 |
|
|
ii. Unburden the low level drivers from having to export the
|
18 |
|
|
character node device and related handling.
|
19 |
|
|
iii. Implement any policy mechanisms in one place.
|
20 |
|
|
iv. Applications have to interface with only module instead of
|
21 |
|
|
multiple low level drivers.
|
22 |
|
|
|
23 |
|
|
Currently this module (called Common Management Module) is used only to issue
|
24 |
|
|
ioctl commands. But this module is envisioned to handle all user space level
|
25 |
|
|
interactions. So any 'proc', 'sysfs' implementations will be localized in this
|
26 |
|
|
common module.
|
27 |
|
|
|
28 |
|
|
Credits:
|
29 |
|
|
-------
|
30 |
|
|
|
31 |
|
|
"Shared code in a third module, a "library module", is an acceptable
|
32 |
|
|
solution. modprobe automatically loads dependent modules, so users
|
33 |
|
|
running "modprobe driver1" or "modprobe driver2" would automatically
|
34 |
|
|
load the shared library module."
|
35 |
|
|
|
36 |
|
|
- Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML
|
37 |
|
|
|
38 |
|
|
"As Jeff hinted, if your userspace<->driver API is consistent between
|
39 |
|
|
your new MPT-based RAID controllers and your existing megaraid driver,
|
40 |
|
|
then perhaps you need a single small helper module (lsiioctl or some
|
41 |
|
|
better name), loaded by both mptraid and megaraid automatically, which
|
42 |
|
|
handles registering the /dev/megaraid node dynamically. In this case,
|
43 |
|
|
both mptraid and megaraid would register with lsiioctl for each
|
44 |
|
|
adapter discovered, and lsiioctl would essentially be a switch,
|
45 |
|
|
redirecting userspace tool ioctls to the appropriate driver."
|
46 |
|
|
|
47 |
|
|
- Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML
|
48 |
|
|
|
49 |
|
|
Design:
|
50 |
|
|
------
|
51 |
|
|
|
52 |
|
|
The Common Management Module is implemented in megaraid_mm.[ch] files. This
|
53 |
|
|
module acts as a registry for low level hba drivers. The low level drivers
|
54 |
|
|
(currently only megaraid) register each controller with the common module.
|
55 |
|
|
|
56 |
|
|
The applications interface with the common module via the character device
|
57 |
|
|
node exported by the module.
|
58 |
|
|
|
59 |
|
|
The lower level drivers now understand only a new improved ioctl packet called
|
60 |
|
|
uioc_t. The management module converts the older ioctl packets from the older
|
61 |
|
|
applications into uioc_t. After driver handles the uioc_t, the common module
|
62 |
|
|
will convert that back into the old format before returning to applications.
|
63 |
|
|
|
64 |
|
|
As new applications evolve and replace the old ones, the old packet format
|
65 |
|
|
will be retired.
|
66 |
|
|
|
67 |
|
|
Common module dedicates one uioc_t packet to each controller registered. This
|
68 |
|
|
can easily be more than one. But since megaraid is the only low level driver
|
69 |
|
|
today, and it can handle only one ioctl, there is no reason to have more. But
|
70 |
|
|
as new controller classes get added, this will be tuned appropriately.
|