| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
... so that it cannot be stopped while there are active arrays.
I don't know where that second 'close' came from ....
|
| |
|
|
| |
More here
|
| |
|
|
|
| |
Data is being passed in shared memory, so the pipe is only being
use as a wakeup. This can more easily be done with a thread-signal.
|
| |
|
|
|
|
| |
The returned value was never used, and we don't really want
this return path anyway as writing to a pipe could conceivably
block, and the monitor must not block.
|
| |
|
|
| |
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| | |
|
| |
|
|
| |
It is never used.
|
| |
|
|
|
|
| |
When an array becomes inactive, clean up and forget it.
This involves signalling the manager.
|
| |
|
|
| |
The container has an ->arrays field that we should be using.
|
| |
|
|
|
|
|
|
|
|
|
| |
From: Dan Williams <dan.j.williams@intel.com>
Each md_message encapsulates a single command. A command includes an 'action'
member which describes what if any data comes after the action. Communication
with the monitor involves updating the active_cmd pointer and then writing to
mgr_pipe. Pass/fail status is returned via mon_pipe.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
|
|
|
|
| |
From: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
| |
|
