Question regarding liblvm2cmd

Hello,

I am working with liblvm2cmd within a program that aims to simplify typical LV management tasks from a web interface. Using the library allows me to accomplish this with better sanity and safety.

I noticed that lvm2_run() only has a few possible return values and does not set a global errno to give more information as to why something may have failed. I inspected lvm2_run() and _run_command() in tools/.

For instance, if you try to create a LV of a size that exceeds the capacity of the given VG, its easy to tell that something went wrong and print the response from lvm in the callback. However, it seems rather difficult for the calling function to know what went wrong. The user knows, obviously, by what is printed.

Barring picking apart the strings that would be printed for any given level, is there some other way to make a program understand the nature of a failure?

Many thanks in advance.

Cheers,
--Tim

This is a tricky one. Work has begun on developing a proper library, but the error handling mechanism is not yet resolved. I am reluctant to see 1001 specific lvm2 error codes introduced - this would be a maintenance and documentation headache - but doing things errno-style might be an acceptable compromise. My question is usually: 'But how can the caller make genuine use of the error code?' - if it failed, it failed, how does having a specific error code really help?

Alasdair

[email protected]

That would be a nightmare, agreed.

Its not really too urgent, its very easy to see where messages come from and modify the output (or set some global) and statically link against the library. This avoids modifying the system LVM which is good.

Considering system() or execv() as an alternate, I love the library as-is :)

Really, it boils down to less values that most standard libc functions would set.

Generically:

* Its too big
* It doesn't exist
* It already exists
* Its busy
* Generic failure

.. I may be forgetting one.

Well, out of the five possible ways to set errno listed above .. all but one (could) be remedied by the caller. For instance, if creating an lv and ETOOBIG is returned .. make it smaller (or re-scan, as someone else has obviously created a LV since we last looked). The same may go for EEXISTS, EBUSY is obvious.

Of course each level is more meaningful in the context of the last command issued.

The real time consuming pain would be implementing it.

Cheers,
--Tim