summaryrefslogtreecommitdiff
path: root/libdm/libdm-report.c
Commit message (Collapse)AuthorAgeFilesLines
* libdm: report: fix escaping of JSON quote char in reported fieldsPeter Rajnoha2022-08-241-8/+3
| | | | | | | | | | | | | | | | | | Commit 73ec3c954b21522352b6f5cce9a700d6bf30ccf4 added a way to print only a part of the report string (repstr) to support decoding individual string list items out of repstr. The repstr is normally printed through _safe_repstr_output so that any JSON_QUOTE character ('"') found within the repstr is escaped to not interfere with value quoting in JSON format. However, the commit 73ec3c954b21522352b6f5cce9a700d6bf30ccf4 missed checking the 'len' argument passed to _safe_repstr_output function when adding the rest of the repstr after all previous JSON_QUOTE characters were escaped (when calling the last dm_pool_grow_object). When 'len' is 0, we need to calculate the 'len' ourselves in the function by simply calling strlen. This is because 'len' is passed to the function only if we're taking a part of repstr, not as a whole.
* libdm: report: use proper JSON array for string list output in JSON_STD formatPeter Rajnoha2022-08-111-4/+84
| | | | | | | | | | In JSON format, we print string list this way: "key" = "item1,item2,...,itemN" while in JSON_STD format, we print string list this way: "key" = ["item1","item2",...,"itemN"]
* libdm: report: separate basic and JSON+JSON_STD format in _output_fieldPeter Rajnoha2022-08-111-71/+94
| | | | | Use separate functions to handle basic and JSON+JSON_STD format. It's clearer this way than interleaving both in the same function.
* libdm: report: enhance the way string list is stored internallyPeter Rajnoha2022-08-111-116/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, we stored only the report string itself for a string list in field->report_string. The field->report_string has either sorted items or not, depending on what we need for a field - some report fields have sorted output, some don't... The field->sort_value.value then contains pointer to the exact field->report_string. The field->sort_value.items ALWAYS keeps sorted array of individual items, represented as '[position,length]' pairs pointing to the field->sort_value.value string. This approach was fine as far as we didn't need to apply further formatting to field->report_string. However, if we need to apply further formatting to field->report_string content, taking into account individual items, we also need to know where each item starts and what is its length. Before, we only knew this when items in report string were sorted, but not in the unsorted version. We can't rely on the delimiter (default ",") only to separate items back out of report string, because that delimiter can be contained in the item value itself. So this patch enhances the field->report_string for a string list so it also contains '[position,length]' pairs for each individual item inside field->report_string. We store this array right beyond the string itself and we encode it in the same manner we already did for field->sort_value.items before. If field->report_string has sorted items, the field->sort_value.items just points to the array of items we store beyond the report string. If field->report_string has unsorted items, we store separate array of items for both field->report_string and field->sort_value. This patch also cleans up the _report_field_string_list function a bit so it's easier and more straightforward to follow than the original version. Example. If we have "abc", "xy", "defgh" as list on input with "," as delimiter, then: - field->report_string will have: - if we need field->report_string unsorted: abc,xy,defgh\0{[3,12],[0,3],[4,2],[7,5]} |____________||________________________| string array of [pos,len] pairs |____||________________| #items items - if we need field->report_string sorted: repstr_extra | V abc,defgh,xy\0{[3,12],[0,3],[4,5],[10,2]} |____________||________________________| string array of [pos,len] pairs |____||________________| #items items - field->sort_value will have: - if field->report_string is unsorted: field->sort_value.value = field->report_string field->sort_value.items = {[0,3],[0,3],[7,5],[4,2]} (that is 'abc,defgh,xy') - if field->report_string is sorted already: field->sort_value.value = field->report_string field->sort_value.items = repstr_extra (that is also 'abc,defgh,xy')
* libdm: report: use 'null' for undefined numeric values in JSON_STD outputPeter Rajnoha2022-08-111-1/+7
| | | | | | | | | | | | | | | For JSON_STD format, use 'null' if a field has no value at all. In JSON format, we print undefined numeric values this way: "key" = "" while in JSON_STD format, we print undefined numeric values this way: "key" = null (Keep in mind that 'null' is different from 0 (zero value) which is a defined value.)
* libdm: report: remove double quotes around numeric values in JSON_STD outputPeter Rajnoha2022-08-111-7/+20
| | | | | | | | | | | | In JSON format, we print numeric values this way: "key" = "N" while in JSON_STD format, we print numeric value this way: "key" = N (Where N is a numeric value.)
* libdm: report: add DM_REPORT_GROUP_JSON_STD groupPeter Rajnoha2022-08-111-2/+11
| | | | | | | The original JSON formatting will be still available using the original DM_REPORT_GROUP_JSON identifier. Subsequent patches will add enhancements to JSON formatting code so that it adheres more to JSON standard - this will be identified by new DM_REPORT_GROUP_JSON_STD identifier.
* cov: add some initializersZdenek Kabelac2021-09-131-4/+4
|
* clang: always initialized valuesZdenek Kabelac2021-04-231-1/+1
|
* libdm: eliminate some abi-dumper errorsZdenek Kabelac2021-04-061-3/+3
| | | | | | | | | ABI dumper does not like missing enum/union/struct names, so add them with _e, _u suffix. Usage reference: https://doc.dpdk.org/guides-16.04/contributing/versioning.html
* libdm: simplify line emitter checkingZdenek Kabelac2021-02-101-1/+1
|
* cov: split check for type assignmentZdenek Kabelac2018-11-031-4/+5
| | | | | | | Check that type is always defined, if not make it explicit internal error (although logged as debug - so catched only with proper lvm.conf setting). This ensures later type being NULL can't be dereferenced with coredump.
* cov: ensure vars are setZdenek Kabelac2018-10-151-1/+1
| | | | | Make sure, tmp_begin and tmp_end are always set, even for blind coverity.
* build: Don't generate symlinks in include/ dirJoe Thornber2018-05-141-1/+1
| | | | | | | As we start refactoring the code to break dependencies (see doc/refactoring.txt), I want us to use full paths in the includes (eg, #include "base/data-struct/list.h"). This makes it more obvious when we're breaking abstraction boundaries, eg, including a file in metadata/ from base/
* coverity: add some initilizersZdenek Kabelac2017-11-071-1/+1
| | | | | Coverity cannot do a deeper analyzis so let's make just reports go away and initialize them to 0.
* libdm: fix parentheses in assignment + comparisonZdenek Kabelac2017-09-201-1/+1
| | | | | As reported, fix incorrect placement of parentheses. TODO: add testing code.
* tidy: prefer not using else after returnZdenek Kabelac2017-07-201-4/+6
| | | | | clang-tidy: avoid using 'else' after return - give more readable code, and also saves indention level.
* cleanup: add braces in macroZdenek Kabelac2017-07-201-2/+2
|
* cleanup: drop extra compareZdenek Kabelac2017-07-171-2/+2
| | | | dm_free() already validates for NULL itself.
* numbers: strtod or strtoul need reset of errnoZdenek Kabelac2017-07-171-0/+4
| | | | | | API for strtod() or strtoul() needs reset of errno, before it's being called. So add missing resets in missing places and some also some errno validation for out-of-range numbers.
* libdm: use rounded float for percent printZdenek Kabelac2017-06-241-1/+1
| | | | | Use new added dm_percent_to_round_float to enhance print of percentage values.
* libdm: implement dm_percent_to_round_floatZdenek Kabelac2017-06-241-0/+23
| | | | | | | | | | | | | | | | | | | Add function to adjust printing of percent values in better way. Rounding here is going along following rules: 0% & 100% are always clearly reported with .0 decimal points. Values slightly above 0% we make sure a nearest bigger non zero value with given precission is printed (i.e. 0.01 for %.2f will be shown) For values closely approaching 100% we again detect and adjust value that is less then 100 when printed. (i.e. 99.99 for %.2f will be shown). For other values we are leaving them with standard rounding mechanism since we care mainly about corner values 0 & 100 which need to be printed precisely.
* cleanup: use matching signed number comparationZdenek Kabelac2017-02-131-1/+1
|
* cleanup: use fall throughZdenek Kabelac2017-02-131-0/+5
| | | | gcc gets 'selective' on having commented fall through case.
* cov: use unsigned for single bit valuesZdenek Kabelac2016-12-121-2/+2
| | | | Avoid using signed int.
* libdm: check for mem when _canonicalize_field_idsZdenek Kabelac2016-10-031-1/+4
| | | | Add missing check for dm_pool_strdup() call (Coverity).
* libdm: report: add dm_report_group_output_and_pop_allPeter Rajnoha2016-08-091-38/+21
| | | | | | | | | | | | The dm_report_group_output_and_pop_all calls dm_report_output and dm_report_group_pop for all the items that are currently in report group. This is just a shortcut that makes it easier to output and pop group's content so the group handle can be reused again without a need to initialize and configure it again. The functionality of dm_report_group_output_and_pop_all is the same as dm_report_destroy but without destroying the report group handle.
* libdm: report: postpone printing of JSON starting '{' character till it's neededPeter Rajnoha2016-08-091-36/+14
| | | | | | | | | | This patch moves printing of starting '{' character for JSON output up untili it's known there's any further output following - either the content or ending '}' character. Also, remove unnecessary switch for different report group types and calling individual functions to handle dm_report_group_create as that code is shared for all existing types at the moment.
* libdm: report: add dm_report_destroy_rowsPeter Rajnoha2016-08-091-0/+5
| | | | | | | | | | | | | Calling dm_report_destroy_rows makes it possible to destroy any report content we have but at the same time it doesn't destroy the report handle itself, thus it's possible to reuse that handle again for new report content. Functionally, this is the same as calling dm_report_output with the report handle but omitting the output iself. This functionality may be useful if we, for whatever reason, need to discard the report content and start a fresh new one but with the same report configuration and initialization and thus we can just reuse the existing handle.
* libdm: report: fix json reporting to escape '"' character that may appear in ↵Peter Rajnoha2016-07-261-3/+29
| | | | reported string
* libdm: report: fix field width calculation when using dm_report_column_headingsPeter Rajnoha2016-06-281-24/+41
| | | | | | | | | | | | | This fixes commit 0ba5f4b8e977a6f2f45f95777da508b42d84c01a which moved field recalculation (field width and sort position) from dm_report_object to dm_report_output but it didn't handle the case when dm_report_column_headings was used separately to report headings (before dm_report_outpout call) and hence we ended up with intial widths for fields in the headings. If we're using dm_report_column_headings, we need to recalculate fields if we haven't done so yet, the same way as we do in dm_report_output.
* coverity: fix issues detected in recent codePeter Rajnoha2016-06-281-2/+2
| | | | | | | | | | | | | | Uninitialized variables (UNINIT) /safe/guest2/covscan/LVM2.2.02.158/tools/toollib.c: 3520 in _process_pvs_in_vgs() Uninitialized variables (UNINIT) Using uninitialized value "do_report_ret_code". Null pointer dereferences (REVERSE_INULL) /safe/guest2/covscan/LVM2.2.02.158/libdm/libdm-report.c: 4745 in dm_report_output() Null pointer dereferences (REVERSE_INULL) Null-checking "rh" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. Incorrect expression (MISSING_COMMA) /safe/guest2/covscan/LVM2.2.02.158/lib/log/log.c: 280 in _get_log_level_name() Incorrect expression (MISSING_COMMA) In the initialization of "log_level_names", a suspicious concatenated string ""noticeinfo"" is produced. Null pointer dereferences (FORWARD_NULL) /safe/guest2/covscan/LVM2.2.02.158/tools/reporter.c: 816 in_get_report_options() Null pointer dereferences (FORWARD_NULL) Comparing "mem" to null implies that "mem" might be null.
* libdm: log: remove log_print_bypass_report calls and register new ↵Peter Rajnoha2016-06-231-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | print_log_libdm for libdm during lvm initialization instead This fixes commit f50d4011cdd3ef38c15b9dea05e73321592d93c2 which introduced a problem when using older lvm2 code with newer libdm. In this case, the old LVM didn't recognize new _LOG_BYPASS_REPORT flag that libdm-report code used. This ended up with no output at all from libdm where log_print_bypass_report was called because the _LOG_BYPASS_REPORT was not masked properly in lvm2's print_log fn which was called as callback function for logging. With this patch, the lvm2 registers separate print_log_libdm logging function for libdm instead. The print_log_libdm is exactly the same as print_log (used throughout lvm2 code) but it checks whether we're printing common line on output where "common" means not going to stderr, not a warning and not an error and if we are, it adds the _LOG_BYPASS_REPORT flag so the log_print goes directly to output, not to any log report. So this achieves the same goal as in f50d4011cdd3ef38c15b9dea05e73321592d93c2, just doing it in a way that newer libdm is still compatible with older lvm2 code (libdm-report is the only code using log_print). Looking at the opposite mixture - older libdm with newer lvm2 code, that won't be compilable because the new log report functionality that is in lvm2 also requires new dm_report_group_* libdm functions so we don't need to care here.
* libdm: select: recognize special selection string 'all' as an alias for ↵Peter Rajnoha2016-06-201-1/+3
| | | | blank selection string
* libdm: report: add dm_report_set_selectionPeter Rajnoha2016-06-201-31/+93
| | | | | Since we can do repeated dm_report_output calls now, we also like to be able to set selection for each of these outputs.
* libdm: report: add DM_REPORT_OUTPUT_MULTIPLE_TIMES report flag to keep ↵Peter Rajnoha2016-06-201-26/+57
| | | | | | | | | report data even after output is done The DM_REPORT_OUTPUT_MULTIPLE_TIMES instructs reporting code to keep rows even after dm_report_output call - the rows are not destroyed in this case which makes it possible to call dm_report_output multiple times.
* refactor: move field width calculation and sort preparation from ↵Peter Rajnoha2016-06-201-12/+16
| | | | | | _do_report_object to dm_report_output This also prepares code for repeated dm_report_output calls.
* libdm: report: remember special field to display selection status in struct ↵Peter Rajnoha2016-06-201-6/+7
| | | | | | | | | row's field_sel_status variable This allows for moving parts of the code from dm_report_object to dm_report_output which is important for subsequent patches that allow for repeated dm_report_output, not destroying rows on each dm_report_output call.
* log: also pass log_print through report and add log_print_bypass_report for ↵Peter Rajnoha2016-06-201-16/+16
| | | | | | | | | | | | | | | | | | | use in libdm-report for direct print without report log_print is used during cmd line processing to log the result of the operation (e.g. "Volume group vg successfully changed" and similar). We don't want output from log_print to be interleaved with current reports from group where log is reported as well. Also, the information printed by log_print belongs to the log report too, so it should be rerouted to log report if it's set. Since the code in libdm-report which is responsible for doing the report output uses log_print too, we need to use a different kind of log_print which bypasses any log report currently used for logging (...simply, we can't call log_print to output the log report itself which in turn would again reroute to report - the report would never get on output this way).
* libdm: report: implement DM_REPORT_GROUP_JSON for JSON report outputPeter Rajnoha2016-06-201-11/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces DM_REPORT_GROUP_JSON report group type. When using this group type and when pushing a report to such a group, these flags are automatically unset: DM_REPORT_OUTPUT_ALIGNED DM_REPORT_OUTPUT_HEADINGS DM_REPORT_OUTPUT_COLUMNS_AS_ROWS ...and this flag is set: DM_REPORT_OUTPUT_BUFFERED The whole group is encapsulated in { } for the outermost JSON object and then each report is reported on output as array of objects where each object is the row from report: { "report_name1": [ {field1="value", field2="value",...}, {field1="value", field2="value",...} ... ], "report_name2": [ {field1="value", field2="value",...}, {field1="value", field2="value",...} ... ] ... }
* libdm: report: implement DM_REPORT_GROUP_BASIC for extended report outputPeter Rajnoha2016-06-201-1/+69
| | | | | | | | | | | | | | | | | | | | This patch introduces DM_REPORT_GROUP_BASIC report group type. This type has exactly the classical output format as we know from before introduction of report groups. However, in addition to that, it allows to put several reports into a group - this is the very basic grouping scheme that doesn't change the output format itself: Report: report1_name Header1 Header2 ... value value ... value value ... ... ... ... Report: report2_name Header1 Header2 ... value value ... value value ... ... ... ...
* libdm: report: implement DM_REPORT_GROUP_SINGLE for a group containing ↵Peter Rajnoha2016-06-201-0/+50
| | | | | | | | single report only There's no change in output for this report group type - with this type, we only make sure there's always only one report in a group at a time, not more.
* libdm: report: introduce dm_report_groupPeter Rajnoha2016-06-201-4/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces DM report group (represented by dm_report_group structure) that is used to group several reports to make a whole. As a whole, all the reports in the group follow the same settings and/or formatting used on output and it controls that the output is properly ordered (e.g. the output from different reports is not interleaved which would break readability and/or syntax of target output format used for the whole group). To support this feature, there are 4 new functions: - dm_report_group_create - dm_report_group_push - dm_report_group_pop - dm_report_group_destroy From the naming used (dm_report_group_push/pop), it's clear the reports are pushed onto a stack. The rule then is that only the report on top of the stack can be reported (that means calling dm_report_output). This way we make sure that the output is not interleaved and provides determinism and control over the output. Different formats may allow or disallow some of the existing report flags controlling output itself (DM_REPORT_OUTPUT_*) to be set or not so once the report is pushed to a group, the grouping code makes sure that all the reports have compatible flags set and then these flags are restored once each report is popped from the report group stack. We also allow to push/pop non-report item in which case such an item creates a structure (e.g. to put several reports together with any opening and/or closing lines needed on output which pose as extra formatting structure besides formatting the reports). The dm_report_group_push function accepts an argument to pass any format-specific data needed (e.g. handle, name, structures passed along while working with reports...). We can call dm_report_output directly anytime we need (with the only restriction that we can call dm_report_output only for the report that is currently on top of the group's stack). Or we don't need to call dm_report_output explicitly in which case all the reports in a stack are reported on output automatically once we call dm_report_group_destroy.
* cleanup: use #define for field's quote and pair character and also for the ↵Peter Rajnoha2016-04-081-13/+18
| | | | error msg while extending output line
* cleanup: use sizeof instead of macro.Zdenek Kabelac2016-02-231-4/+4
| | | | | Keep the buffer size defined at a single place and then use its sizeof.
* libdm: fix string boundaryZdenek Kabelac2016-02-231-2/+3
| | | | | The test for string 'end' needs to account for ending \0, which also needs to fit <SIZE.
* doc: change fsf addressZdenek Kabelac2016-01-211-1/+1
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
* cleanup: cast resulting value explicitelyZdenek Kabelac2015-11-191-1/+1
|
* cleanup: add stack tracesZdenek Kabelac2015-11-181-2/+2
|
* libdm: report: consolidate use of string list selection structuresPeter Rajnoha2015-11-181-16/+16
|
View Lorry Controller Status