Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | Notes on Management Module |
| 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 3 | |
| 4 | Overview: |
| 5 | -------- |
| 6 | |
Matt LaPlante | 2fe0ae7 | 2006-10-03 22:50:39 +0200 | [diff] [blame] | 7 | Different classes of controllers from LSI Logic accept and respond to the |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 |
Matt LaPlante | 2fe0ae7 | 2006-10-03 22:50:39 +0200 | [diff] [blame] | 11 | interfaces with the applications on one side and all the low level drivers |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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. |