[doc] Clarify custom hardware manager inheritance
Change-Id: I94657967763f058fccd4f19656925d02cd8973b8
This commit is contained in:
parent
f45d2cc0e7
commit
9dd968fa30
@ -32,12 +32,13 @@ server).
|
||||
|
||||
How can I build a custom HardwareManager?
|
||||
-----------------------------------------
|
||||
Custom HardwareManagers should subclass hardware.HardwareManager or
|
||||
hardware.GenericHardwareManager. The only required method is
|
||||
evaluate_hardware_support(), which should return one of the enums
|
||||
in hardware.HardwareSupport. Hardware support determines which hardware
|
||||
manager is executed first for a given function (see: "`How are methods
|
||||
executed on HardwareManagers?`_" for more info). Common methods you
|
||||
In general, custom HardwareManagers should subclass hardware.HardwareManager.
|
||||
Subclassing hardware.GenericHardwareManager should only be considered if the
|
||||
aim is to raise the priority of all methods of the GenericHardwareManager.
|
||||
The only required method is evaluate_hardware_support(), which should return
|
||||
one of the enums in hardware.HardwareSupport. Hardware support determines
|
||||
which hardware manager is executed first for a given function (see: "`How are
|
||||
methods executed on HardwareManagers?`_" for more info). Common methods you
|
||||
may want to implement are ``list_hardware_info()``, to add additional hardware
|
||||
the GenericHardwareManager is unable to identify and ``erase_devices()``, to
|
||||
erase devices in ways other than ATA secure erase or shredding.
|
||||
|
Loading…
x
Reference in New Issue
Block a user