diff options
Diffstat (limited to 'kernel/Documentation/scsi/megaraid.txt')
| -rw-r--r-- | kernel/Documentation/scsi/megaraid.txt | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/kernel/Documentation/scsi/megaraid.txt b/kernel/Documentation/scsi/megaraid.txt new file mode 100644 index 000000000..3c7cea51e --- /dev/null +++ b/kernel/Documentation/scsi/megaraid.txt @@ -0,0 +1,70 @@ + Notes on Management Module + ~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Overview: +-------- + +Different classes of controllers from LSI Logic accept and respond to the +user applications in a similar way. They understand the same firmware control +commands. Furthermore, the applications also can treat different classes of +the controllers uniformly. Hence it is logical to have a single module that +interfaces with the applications on one side and all the low level drivers +on the other. + +The advantages, though obvious, are listed for completeness: + + i. Avoid duplicate code from the low level drivers. + ii. Unburden the low level drivers from having to export the + character node device and related handling. + iii. Implement any policy mechanisms in one place. + iv. Applications have to interface with only module instead of + multiple low level drivers. + +Currently this module (called Common Management Module) is used only to issue +ioctl commands. But this module is envisioned to handle all user space level +interactions. So any 'proc', 'sysfs' implementations will be localized in this +common module. + +Credits: +------- + +"Shared code in a third module, a "library module", is an acceptable +solution. modprobe automatically loads dependent modules, so users +running "modprobe driver1" or "modprobe driver2" would automatically +load the shared library module." + + - Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML + +"As Jeff hinted, if your userspace<->driver API is consistent between +your new MPT-based RAID controllers and your existing megaraid driver, +then perhaps you need a single small helper module (lsiioctl or some +better name), loaded by both mptraid and megaraid automatically, which +handles registering the /dev/megaraid node dynamically. In this case, +both mptraid and megaraid would register with lsiioctl for each +adapter discovered, and lsiioctl would essentially be a switch, +redirecting userspace tool ioctls to the appropriate driver." + + - Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML + +Design: +------ + +The Common Management Module is implemented in megaraid_mm.[ch] files. This +module acts as a registry for low level hba drivers. The low level drivers +(currently only megaraid) register each controller with the common module. + +The applications interface with the common module via the character device +node exported by the module. + +The lower level drivers now understand only a new improved ioctl packet called +uioc_t. The management module converts the older ioctl packets from the older +applications into uioc_t. After driver handles the uioc_t, the common module +will convert that back into the old format before returning to applications. + +As new applications evolve and replace the old ones, the old packet format +will be retired. + +Common module dedicates one uioc_t packet to each controller registered. This +can easily be more than one. But since megaraid is the only low level driver +today, and it can handle only one ioctl, there is no reason to have more. But +as new controller classes get added, this will be tuned appropriately. |