From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Sat, 16 Apr 2005 15:20:36 -0700 Subject: Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! --- Documentation/scsi/megaraid.txt | 70 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/scsi/megaraid.txt (limited to 'Documentation/scsi/megaraid.txt') diff --git a/Documentation/scsi/megaraid.txt b/Documentation/scsi/megaraid.txt new file mode 100644 index 00000000000..ff864c0f494 --- /dev/null +++ b/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 +interefaces 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. -- cgit v1.2.3