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 practice' 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 practices 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.