cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

megaraid.rst (3134B)


      1.. SPDX-License-Identifier: GPL-2.0
      2
      3==========================
      4Notes on Management Module
      5==========================
      6
      7Overview
      8--------
      9
     10Different classes of controllers from LSI Logic accept and respond to the
     11user applications in a similar way. They understand the same firmware control
     12commands. Furthermore, the applications also can treat different classes of
     13the controllers uniformly. Hence it is logical to have a single module that
     14interfaces with the applications on one side and all the low level drivers
     15on the other.
     16
     17The advantages, though obvious, are listed for completeness:
     18
     19	i.	Avoid duplicate code from the low level drivers.
     20	ii.	Unburden the low level drivers from having to export the
     21		character node device and related handling.
     22	iii.	Implement any policy mechanisms in one place.
     23	iv.	Applications have to interface with only module instead of
     24		multiple low level drivers.
     25
     26Currently this module (called Common Management Module) is used only to issue
     27ioctl commands. But this module is envisioned to handle all user space level
     28interactions. So any 'proc', 'sysfs' implementations will be localized in this
     29common module.
     30
     31Credits
     32-------
     33
     34::
     35
     36	"Shared code in a third module, a "library module", is an acceptable
     37	solution. modprobe automatically loads dependent modules, so users
     38	running "modprobe driver1" or "modprobe driver2" would automatically
     39	load the shared library module."
     40
     41- Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML
     42
     43::
     44
     45	"As Jeff hinted, if your userspace<->driver API is consistent between
     46	your new MPT-based RAID controllers and your existing megaraid driver,
     47	then perhaps you need a single small helper module (lsiioctl or some
     48	better name), loaded by both mptraid and megaraid automatically, which
     49	handles registering the /dev/megaraid node dynamically. In this case,
     50	both mptraid and megaraid would register with lsiioctl for each
     51	adapter discovered, and lsiioctl would essentially be a switch,
     52	redirecting userspace tool ioctls to the appropriate driver."
     53
     54- Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML
     55
     56Design
     57------
     58
     59The Common Management Module is implemented in megaraid_mm.[ch] files. This
     60module acts as a registry for low level hba drivers. The low level drivers
     61(currently only megaraid) register each controller with the common module.
     62
     63The applications interface with the common module via the character device
     64node exported by the module.
     65
     66The lower level drivers now understand only a new improved ioctl packet called
     67uioc_t. The management module converts the older ioctl packets from the older
     68applications into uioc_t. After driver handles the uioc_t, the common module
     69will convert that back into the old format before returning to applications.
     70
     71As new applications evolve and replace the old ones, the old packet format
     72will be retired.
     73
     74Common module dedicates one uioc_t packet to each controller registered. This
     75can easily be more than one. But since megaraid is the only low level driver
     76today, and it can handle only one ioctl, there is no reason to have more. But
     77as new controller classes get added, this will be tuned appropriately.