projects / linux.git / blame
| Commit | Line | Data |
|---|---|---|
| 1da177e4 LT |
1 | Notes on Management Module |
| 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 3 | ||
| 4 | Overview: | |
| 5 | -------- | |
| 6 | ||
| 2fe0ae78 | 7 | Different classes of controllers from LSI Logic accept and respond to the |
| 1da177e4 LT |
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 | |
| 2fe0ae78 | 11 | interfaces with the applications on one side and all the low level drivers |
| 1da177e4 LT |
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 ([email protected]), 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, ([email protected]), 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. |