There are at least two possible approaches to libLVM, and each have their own merits.
One approach is to have libLVM strictly mimic the LVM CLI, albeit in a more well-defined way than the existing string-based liblvmcmd library. A second approach is a more low-level API, based on LVM objects (the PV, VG, and LV), with finer-grained operations on these objects focusing on a get/set paradigm of object attributes.
In the first approach, where the library simply mimicks the CLI, things like PVs, VGs, and LVs would be specified simply by their names, as is done on the CLI. The most common options for each operation would be supported, and other options could be added over time. Operations which would result in ambiguous or hard to handle errors may be restricted or broken into multiple operations such that the error is less ambiguous (for example, a pvcreate operation may be restricted to a single PV, and the caller would just call the pvcreate operation multiple times). This approach has the following advantages:
- It is most likely the fastest way to produce a library
- It should solve the problem of misuse of LVM as the operations will be more defined
- All the locking is handled internal to the operation, and no locks are held upon return from an operation
- Use of parameter structures isolates application memory from libLVM
The disadvantages of the CLI approach are:
- Operations are more high-level, as a result errors are more coarse
- Code does not look as elegant as with the object based approach
- More overhead as attributes need to be copied into structures to be read
The second approach, the object based approach, is different from the first approach to mimicking the CLI in that the objects are more low-level, and many, if not all, LVM operations are implemented simply by modifying one or more attributes of the LVM objects. While the object based approach may certainly have similarities to the CLI approach, the key difference is that handles to objects are obtained first, then attributes are queried or changed based on these handles. The CLI approach simply names things based on device paths and APIs are the operations themselves.
Advantages to the object based approach are:
- Low-level design will most likely facilitate formation of other LVM tools
- Provides very fine-grained errors
- Same object API will be used with existing LVM CLI tools
Disadvantages of the object based approach are:
- Might take longer to get a first release of libLVM
- Most likely harder for a consumer to program, as it will diverge from the CLI that they are most likely accustomed to
- Locking is tied to an object handle rather than an operation. This makes it possible for an application to hold a lock longer than intended resulting in programming errors such as deadlock, holding too many open files, etc
- Certain CLI operations might require more API calls in an object-based approach than they would in a CLI approach.