summaryrefslogtreecommitdiffstats
path: root/liblvm
Commit message (Collapse)AuthorAgeFilesLines
...
* INSTALL rules updatesZdenek Kabelac2010-04-091-33/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Patch is inspired by Debian's extra patch. - removes OWNER & GROUP make vars they are parts of INSTALL command. - adds INSTALL_PROGRAM for executable, uses $(INSTALL) - adds INSTALL_DATA for non-executable data, uses ($INSTALL) - adds INSTALL_WDATA for writable non-executable data, uses ($INSTALL) - adds configure option --enable-write_install - to support installatin of writable files used by distribution - replaces usage of ifeq @LIB_SUFFIX@ with $(LIB_SUFFIX) - installs .a files from static builds without executable flag - installs .a files to $(usrlibdir) instead of $(libdir) - installs all static binaries to $(staticdir) - create .so links for devel package in $(usrlibdir) instead of $(libdir) - makes .so and .so.LIB_VERSION files within builddir - removes VERSIONED_SHLIB and created versioned LIB_SHARED automagicaly - install LIB_SHARED via install_lib_shared target - install plugins via install_lib_shared_plugin target - prints whole 'install' command during installation instead of less informative "Installing $(something) $(somewhere)" - install multiple man pages with one INSTALL command - use DISTCLEAN_TARGETS instead of creating multiple distclean targets
* Use vpath instead of VPATH.Zdenek Kabelac2010-04-091-1/+0
| | | | | | | | | | | | | | | Usage of VPATH makes troubles when used within $(builddir). Not only source files are being found through VPATH, but targets as well. (make --debug=v) Thus if user builds the code in $(srcdir) and also in some $(builddir) he gets mangled results as some generated files (i.e. .export.sym) are 'reused' from $(srcdir) instead of $(builddir). This patch switches to use vpath were we could explicitly name suffixes that should be looked via vpath - we must take care, we do not generate files with these suffixes: .c, .in, .po, .exported_symbols
* Use INTERNAL_ERROR definition consistently in internal error messages.Alasdair Kergon2010-03-253-3/+3
|
* Improve activation monitoring option processingMike Snitzer2010-03-231-0/+1
| | | | | | | | | | | | | . Add "monitoring" option to "activation" section of lvm.conf . Have clvmd consult the lvm.conf "activation/monitoring" too. . Introduce toollib.c:get_activation_monitoring_mode(). . Error out when both --monitor and --ignoremonitoring are provided. . Add --monitor and --ignoremonitoring support to lvcreate. Update lvcreate man page accordingly. . Clarify that '--monitor' controls the start and stop of monitoring in the {vg,lv}change man pages. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
* Disable long living process flag in lvm2app.Milan Broz2010-03-171-1/+2
| | | | | | | | | This option should be configurable, but for now do not set it at all. (lvm2app is used in udisks probers and there cac cause several nasty races when trying to update lvmcache during rescan.)
* Remove unnecessary full_scan parameter from get_vgids and get_vgnames calls.Alasdair Kergon2010-03-161-2/+2
|
* Introduce LVMINTERNAL_LIBSZdenek Kabelac2010-03-041-1/+1
| | | | Keep dependency libraries for liblvm-internal in one place.
* Use $(top_builddir) for inclusion of make.tmpl in Makefiles.Zdenek Kabelac2010-03-041-1/+1
|
* Add Doxygen file for lvm2app to generate documentation from lvm2app.h.Dave Wysochanski2010-02-243-0/+326
| | | | | | A simple Doxygen file for lvm2app documentation. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Update doxygen comments for lvm2app.h.Dave Wysochanski2010-02-241-108/+255
| | | | | | | | | | | | Fix add/remove tag function headers. Fix a lot of little problems with doxygen comments. Clarify the basic objects and their handles, and place functions with their appropriate handles/objects. All this cleanup moves automatic documentation of lvm2app much closer to being useful as official documentation. In the future I will add some examples and plan to build the examples as part of the unit tests. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Add lvm_lv_get_tags(), lvm_lv_add_tag(), and lvm_lv_remove_tag().Dave Wysochanski2010-02-243-0/+86
| | | | | | | | | | Add lvm2app functions to manage LV tags. For lvm_lv_get_tags(), we return a list of tags, similar to other functions that return lists. An empty list is returned if there are no tags. NULL is returned if there is a problem obtaining the list of tags. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Add lvm_vg_get_tags(), lvm_vg_add_tag(), and lvm_vg_remove_tag().Dave Wysochanski2010-02-243-2/+86
| | | | | | | | | | Add lvm2app functions to manage VG tags. For lvm_vg_get_tags(), we return a list of tags, similar to other functions that return lists. An empty list is returned if there are no VG tags. NULL is returned if there is a problem obtaining the list of tags. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Add tag_list_copy() supporting function inside lvm2app.Dave Wysochanski2010-02-241-0/+1
| | | | | | | | | Add a supporting function to copy a list of internal tags to lvm2app list. We need to put this here because of the lvm_str_list_t type which we export in lvm2app.h. If we didn't export this type, we could put this in the internal library and use struct str_list. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* post-releaseAlasdair Kergon2010-02-163-9/+10
|
* Update lvm2app.h comments to remove hidden VG comment list vgnames/vgids.Dave Wysochanski2010-02-151-4/+0
| | | | | Peter recently fixed lvm_list_vg_names() and lvm_list_vg_uuids() so they no longer return hidden names. Remove the comment in lvm2app.h.
* Export lvm_pv_get_size(), lvm_pv_get_free(), lvm_pv_get_dev_size in lvm2app.Dave Wysochanski2010-02-143-0/+52
| | | | | | | | We add these exports to show the pv_size and pv_free and dev_size fields. Fixes rhbz561423. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Fix off by 512 sizes for lvm2app.Dave Wysochanski2010-02-142-6/+6
| | | | | | | | | | Internally we store sizes in sectors, but lvm2app exports sizes in bytes. We could get fancier and allow units configuration but this fix should do for now. Fixes rhbz561422. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* This is related to liblvm and its lvm_list_vg_names() and ↵Peter Rajnoha2010-02-031-7/+2
| | | | | | | | | | | | | | | | lvm_list_vg_uuids() functions where we should not expose internal VG names/uuids (the ones with "#" prefix )through the interface. Otherwise, we could end up with library users opening internal VGs which will initiate locking mechanism that won't be cleaned up properly. "#orphans_{lvm1, lvm2, pool}" names are treated in a special way, they are truncated first to "orphans" and this is used as a part of the lock name then (e.g. while calling lvm_vg_open()). When library user calls lvm_vg_close(), the original name "orphans_{lvm1, lvm2, pool}" is used directly and therefore no unlock occurs. We should exclude internal VG names and uuids in the lists provided by lvmcache: lvmcache_get_vgids() and lvmcache_get_vgnames().
* Move error message to locking constructor and printMilan Broz2010-01-221-1/+0
| | | | | | | | more descriptive message if locking fails instead of "Locking type -1 initialisation failed." Use read-only locking instead of misleading ignorelocking option in message.
* Rename pvcreate_params processing functions to better match <object><action>.Dave Wysochanski2009-11-011-1/+1
| | | | | | Rename fill_default_pvcreate_params to pvcreate_params_set_defaults. Rename pvcreate_validate_restore_params to pvcreate_restore_params_validate. Rename pvcreate_validate_params to pvcreate_params_validate.
* Allow calling fill_default_pvcreate_params from tools.Dave Wysochanski2009-10-051-9/+4
| | | | | | | | | We need defaults for pvcreate_params at a higher level - this will allow us to use a common function from the tools to take defaults, then fill in any non-defaults from the commandline. Future patches will refactor vgcreate/vgextend to call this function if one or more pvcreate parameters are given on the commandline.
* Add pvcreate_params to vg_extend.Dave Wysochanski2009-10-051-1/+1
| | | | | | | | | | | | | | | | Another refactoring for implicit pvcreate support. We need to get the pvcreate parameters somehow to the vg_extend routine. Options seemed to be: 1. Attach the parameters to struct volume_group. I personally did not like this idea in most cases, though one could make an agrument why it might be ok at least for some of the parameters (e.g. metadatacopies). 2. Pass them in to the extend routine. This second route seemed to be the best approach given the constraints. Future patches will parse the command line and fill in the actual values for the pvcreate_single call. Should be no functional change.
* Allow for a build directory separate from the source.Alasdair Kergon2009-10-021-2/+3
|
* Fix build failure when enabling dmeventd and applib.Dave Wysochanski2009-09-141-0/+4
| | | | | This patch fixes a build with options similar to the following: ./configure --enable-debug --enable-applib --enable-dmeventd --enable-cmdlib
* Add most relevant vg_attr fields as lvm2app 'get' functions.Dave Wysochanski2009-09-142-0/+52
| | | | | | | | | Of the vgs field vg_attr, a few of the most likely to be used attributes are clustered, exported, and partial. This patch adds the following 3 functions: uint64_t lvm_vg_is_clustered(const vg_t vg) uint64_t lvm_vg_is_exported(const vg_t vg) uint64_t lvm_vg_is_partial(const vg_t vg)
* Add max_pv and max_lv vg 'get' lvm2app exports.Dave Wysochanski2009-09-142-0/+32
|
* Do not override the distclean target in liblvm's Makefile, it annoys make andPetr Rockai2009-09-031-1/+0
| | | | the make.tmpl-included distclean should work better anyway.
* Update lvm_vg_write() to handle the deferred commit of lvm_vg_write().Dave Wysochanski2009-09-022-7/+5
| | | | | | | | | | | | | Now that we've refactored the internal library functions that do the vg_remove, we can handle the deferred commit of a lvm_vg_remove() inside lvm_vg_write(). This makes the VG create/remove API more consistent in terms of disk commits - they now both require an lvm_vg_write() to commit the create or remove to disk. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Author: Dave Wysochanski <dwysocha@redhat.com>
* Split vg_remove_single into 2 functions - the second part commits to disk.Dave Wysochanski2009-09-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | Split vg_remove_single into vg_remove_check (mandatory checks before vgremove) and vg_remove (do actual remove by committing to disk). In liblvm, we'd like to provide an consistent API that allows multiple changes in memory, then let lvm_vg_write() control the commit to disk. In some cases (for example, lvresize calls fsadm) this may not be possible. However, since we are using an object model and dividing things into small operations, the most logical model seems to be the lvm_vg_write model, and handling the special cases as they arrive. So as best as possible we move towards this end. A possible optimization would be to consolidate vg_remove (committing) code with vgreduce code. A second possible optimization is making vgreduce of the last device equivalent to vgremove. Today, lvm_vg_reduce fails if vgreduce is called with the last device, but from an object model perspective we could view this as equivalent to vgremove and allow it. My gut feel is we do not want to do this though. Author: Dave Wysochanski <dwysocha@redhat.com>
* Remove unwanted Makefiles and don't purge lvm2.po that'sFabio M. Di Nitto2009-09-011-0/+1
| | | | under RCS.
* Make lvm2app pv_t handle definition consistent with lvm_t.Dave Wysochanski2009-08-132-10/+10
| | | | | | | This patch update pv_t handle to be consistent with lvm_t - define as a pointer to internal struct physical_volume. Author: Dave Wysochanski <dwysocha@redhat.com>
* Make lvm2app lv_t handle definition consistent with lvm_t.Dave Wysochanski2009-08-132-23/+23
| | | | | | | This patch update lv_t handle to be consistent with lvm_t - define as a pointer to internal struct logical_volume. Author: Dave Wysochanski <dwysocha@redhat.com>
* Make lvm2app vg_t handle definition consistent with lvm_t.Dave Wysochanski2009-08-133-47/+47
| | | | | | | This patch update vg_t handle to be consistent with lvm_t - define as a pointer to internal struct volume_group. Author: Dave Wysochanski <dwysocha@redhat.com>
* Move FIXME from user visible lvm2app.h to lvm_vg.cDave Wysochanski2009-08-032-1/+3
| | | | Author: Dave Wysochanski <dwysocha@redhat.com>
* Fix lvm2app.pc installation filename.Alasdair Kergon2009-07-291-1/+1
|
* Don't include lvm-version.h in exported liblvm file!Dave Wysochanski2009-07-292-1/+1
| | | | Move include of lvm-version.h into lvm_base.c where it belongs.
* Remove unneeded struct on return from lvm_lv_create_linear.Dave Wysochanski2009-07-291-1/+1
| | | | Results in compile warning.
* Remove pv_t, vg_t & lv_t handles from lib. Only liblvm uses them.Alasdair Kergon2009-07-296-11/+11
| | | | Rename lvm.h to lvm2app.h for now.
* Add doxygen mainpage tag to lvm.hDave Wysochanski2009-07-281-1/+3
|
* Add an open_mode to the vg struct for liblvm - enforce read / write semantics.Dave Wysochanski2009-07-282-1/+18
| | | | | | | | | | | | | | For now, a simple way to enforce the read/write semantics is to just save the open mode of the VG. If the caller uses lvm_vg_create, the mode is write. The caller using lvm_vg_open can use either read or write to open the VG. Once we have this, we enforce the permissions on each API call and don't allow a caller to modify a VG that has not been opened properly. This may be better combined with the locking mode, but I view that as future cleanup, past this initial release. The intial release should enforce the basic object semantics though, as described in the lvm.h file. Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
* Add lvm_vg_get_seqno, updating lvm.h and unit test.Dave Wysochanski2009-07-283-0/+32
| | | | | | Adding the ability to get the seqno is important for an application to determine if something has changed in a VG. Otherwise, the only way to know is to open the VG with write permission and hold the handle.
* Update lvm.h - remove remaining FIXMEs, note limitations of a few functions.Dave Wysochanski2009-07-283-11/+47
| | | | Almost done...
* Fix lvm.h formatting.Dave Wysochanski2009-07-281-111/+191
|
* Add lvm_library_get_version() and update unit tests to display version.Dave Wysochanski2009-07-283-0/+20
|
* Use dm_malloc and dm_free in liblvm instead of malloc/free.Dave Wysochanski2009-07-284-15/+15
|
* Rename lvm_create to lvm_init and lvm_destroy to lvm_quit.Dave Wysochanski2009-07-283-19/+19
|
* Update lvm.h to address feeback.Dave Wysochanski2009-07-281-69/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | This addresses a a large amount of Alasdair's review. Subsequent patches will address remaining issues. Addressed: // FIXME Mention that's also required on error. // FIXME Be consistent in terminology. It's called "system_dir" then last sentence says "system directory setting". Is it referring to "system_dir" there or something else? // FIXME Mention it frees all resources and cannot be used subsequently? // FIXME What does "any system configuration" mean? // FIXME Expand on that explanation a bit, now that we know what the other fns look like. // FIXME Not sure about that - it needs to scan sometimes. "will not" or "might not" ? // FIXME: That's a FIXME in the code!!! // FIXME What does "copied" mean in this context??? // FIXME Say what struct the returned struct dm_list is a list of... // FIXME "This API" ? This function creates an object in memory? // FIXME This function commits the Volume Group object referenced by the VG handle to disk? // FIXME Where is "Name" defined? Absolute pathname? Outstanding: // FIXME Version function first? No structs or handles needed for that. // FIXME Sort out this alignment. "Set an" directly below "system_dir" looks awful. Indent differently? More blank lines? // FIXME Check how doxygen processes this. E.g. "return: LVM handle. You must use lvm_error() to check there were no errors and confirm that the handle is valid for passing to other functions." // FIXME Find a better name. lvm_init. // FIXME Consider renaming according to the new name for lvm_create. // FIXME Please can we use dm_malloc throughout?
* Add warning to lvm.h stating API development in progress.Dave Wysochanski2009-07-271-0/+10
|
* Remove unnecessary \n's from log_error in liblvm.Dave Wysochanski2009-07-273-13/+13
|
* Update return code for lvm_config_reload.Dave Wysochanski2009-07-271-1/+1
|
generated by cgit (git 2.34.1) at 2024-05-24 10:27:02 +0000