mirror of
git://sourceware.org/git/lvm2.git
synced 2024-10-27 01:55:10 +03:00
159 lines
5.7 KiB
Plaintext
159 lines
5.7 KiB
Plaintext
Over time, I'd like to refactor the LVM code into these high level modules.
|
|
|
|
|
|
+-------------------------------------------+
|
|
| |
|
|
| User Interface |
|
|
| |
|
|
| |
|
|
+-------------------+-----------------------+
|
|
|
|
|
+--------------------v-----------------------+
|
|
| |
|
|
| LVM Core |
|
|
| |
|
|
| |
|
|
+----+----------------+-----------------+----+
|
|
| | |
|
|
+-----v-----+ +-----v------+ +------v----+
|
|
| | | | | |
|
|
| Device | | Metadata | | System |
|
|
| Mapper | | | | |
|
|
| | | | | |
|
|
| | | | | |
|
|
| | | | | |
|
|
+-----------+ +------------+ +-----------+
|
|
|
|
+---------------------------------------------------------+
|
|
|
|
|
|
+------------------------------------+
|
|
| |
|
|
| Base |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
+------------------------------------+
|
|
|
|
Going from the bottom up we have:
|
|
|
|
Base
|
|
----
|
|
|
|
This holds all our general purpose code such as data structures, regex engine,
|
|
memory allocators. In fact pretty much everything in libdevmapper apart from
|
|
the dm code and config.
|
|
|
|
This can be used by any code in the system, which is why I've drawn a line
|
|
between it and the code above rather than using arrows.
|
|
|
|
If anyone can come up with a better name please do. I'm trying to stay away
|
|
from 'utils'.
|
|
|
|
|
|
Device mapper
|
|
-------------
|
|
|
|
As well as the low level dm-ioctl driving code we need to have all our dm 'best
|
|
practise' stuff in here. For instance this is the code that decides to use the
|
|
mirror target to move some data around; that knows to suspend a thin volume
|
|
before taking a snapshot of it. This module is going to have a lot more code
|
|
in it than the current libdevmapper.
|
|
|
|
It should not know anything about the LVM abstractions or metadata (no PVs, LVs
|
|
or VGs). It just knows about the dm world.
|
|
|
|
Code in here is only allowed to use base.
|
|
|
|
|
|
Metadata model
|
|
--------------
|
|
|
|
Here we have all the format handling, labelling, config parsing etc. We try
|
|
and put *everything* to do with LVM in here that doesn't actually require dm.
|
|
|
|
|
|
System
|
|
------
|
|
|
|
Code that interfaces with the system (udev etc).
|
|
|
|
|
|
LVM Core
|
|
--------
|
|
|
|
[terrible name]
|
|
|
|
This ties together the last 3 units. It should just be glue. We need to be
|
|
strict about pushing code down from here to keep this as small as possible.
|
|
|
|
|
|
User interface
|
|
--------------
|
|
|
|
Self explanatory.
|
|
|
|
|
|
Headers
|
|
-------
|
|
|
|
Headers will be included using sub directories to make it clearer where they
|
|
are in the tree.
|
|
|
|
eg,
|
|
#include "base/mm/pool.h"
|
|
#include "base/data-struct/list.h"
|
|
#include "dm/thin-provisioning.h"
|
|
#include "core/pvmove.h"
|
|
|
|
|
|
Getting there
|
|
=============
|
|
|
|
+-------------------------------------------+
|
|
| |
|
|
| |
|
|
| Tools |
|
|
| |
|
|
| |
|
|
| |
|
|
+---------+------------------------------+--+
|
|
| |
|
|
| +---------------v---------------------------+
|
|
| | |
|
|
| | |
|
|
| | Lib |
|
|
| | |
|
|
| | |
|
|
| | |
|
|
| | |
|
|
| +----------------+--------------------------+
|
|
| |
|
|
| |
|
|
+-----v-------------------------------v-----+
|
|
| |
|
|
| |
|
|
| libdevmapper |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
+-------------------------------------------+
|
|
|
|
This is where I see us now.
|
|
|
|
'base' should be easy to factor out, it's just the non-dm part of libdevmapper
|
|
(ie. the bulk of it). But we have the problem that libdevmapper is a public
|
|
interface to get round.
|
|
|
|
'lib' is where the bulk of our code currently is. Dependency-wise the code is
|
|
a bit like a ball of string. So splitting it up is going to take time. We can
|
|
probably pull code pretty quickly into the 'metadata model' dir. But factoring
|
|
out the dm best practises stuff is going to require splitting at least
|
|
files, and probably functions. Certainly not something that can be done in one
|
|
go. System should just be a question of cherry picking functions.
|
|
|
|
I'm not too familiar with the tools dir. Hopefully it just corresponds with
|
|
the User Interface module and doesn't contain any business logic.
|