diff options
Diffstat (limited to 'Documentation/scsi/megaraid.txt')
-rw-r--r-- | Documentation/scsi/megaraid.txt | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/Documentation/scsi/megaraid.txt b/Documentation/scsi/megaraid.txt new file mode 100644 index 000000000000..ff864c0f494c --- /dev/null +++ b/Documentation/scsi/megaraid.txt | |||
@@ -0,0 +1,70 @@ | |||
1 | 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 | interefaces 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. | ||