Fixes the compilation warning below:
git/libosmocore/src/vty/command.c: In function ‘cmd_complete_command_real’:
git/libosmocore/src/vty/command.c:1953:33: warning: comparison between pointer and zero character const
ant [-Wpointer-compare]
if (vector_slot(vline, index) == '\0')
^~
git/libosmocore/src/vty/command.c:37:0:
git/libosmocore/include/osmocom/vty/vector.h:39:27: note: did you mean to dereference the pointer?
#define vector_slot(V,I) ((V)->index[(I)])
^
git/libosmocore/src/vty/command.c:1953:7: note: in expansion of macro ‘vector_slot’
if (vector_slot(vline, index) == '\0')
^~~~~~~~~~~
Change-Id: Iaba9e3450d68c51e16a7bda2fc0fc370992ca866
Let's not put files of libosmovty into Doxygen groups of libosmocore,
as this seems to confuse Doxygen. Also, some minor updates/fixes
of libosmovty documentation.
Change-Id: I70e612b8d06aabefe634fcd7861641ffb941d974
With stat_item, stats.c and stats_statsd.c, it is becoming a bit
difficult to understand file naming. Also, the 'statistics.c' file
actually only contained osmo_counter handling, so let's rename it to
counter.c altogether.
Change-Id: I2cfb2310543902b7da46cb15a76e2da317eaed7d
In many callers of the VTY API, we are lacking the vty_install_default() step
at certain node levels. This creates nodes that lack the 'exit' command, and
hence the only way to exit such a node is to restart the telnet session.
Historically, the VTY looked for missing commands on the immediate parent node,
and hence possibly found the parent's 'exit' command when the local node was
missing it. That is why we so far did not notice the missing default commands.
Furthermore, some callers call install_default() instead of
vty_install_default(). Only vty_install_default() also includes the 'exit' and
'end' commands. There is no reason why there are two sets of default commands.
To end this confusion, to catch all missing 'exit' commands and to prevent this
from re-appearing in the future, simply *always* install all default commands
implicitly when calling install_node().
In cmd_init(), there are some top-level nodes that apparently do not want the
default commands installed. Keep those the way they are, by changing the
invocation to new install_node_bare() ({VIEW,AUTH,AUTH_ENABLE}_NODE).
Make both install_default() and vty_install_default() no-ops so that users of
the API may still call them without harm. Do not yet deprecate yet, which
follows in Icf5d83f641e838cebcccc635a043e94ba352abff.
Drop all invocations to these two functions found in libosmocore.
Change-Id: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
This change introduces a new command, which could be used to
inspect the application's talloc context directly from VTY.
To enable this feature, an application need to provide it's
context via the 'vty_app_info' struct, and register the VTY
command by calling the osmo_talloc_vty_add_cmds().
The new command is a sub-command of 'show':
show talloc-context <context> <depth> [filter]
Currently the following contexts may be inspected:
- application - a context provided by an application;
- null - all contexts, if NULL-context tracking is enabled.
A report depth is defined by the next parameter, and could be:
- full - full tree report, as the talloc_report_full() does;
- brief - brief tree report, as the talloc_report() does;
- DEPTH - user defined maximal report depth.
Also, there are two optional report filters:
- regexp - print only contexts, matching a regular expression;
- tree - print a specific context, pointed by specified address.
The command output is formatted the same way as in case of calling
the talloc_report() or talloc_report_full().
Change-Id: I43fc42880b22294d83c565ae600ac65e4f38b30d
The 'vty_app_info' struct could be used by some applications to
provide its talloc context. In the future, it will facilitate
the implementation of talloc context introspection via VTY.
But the 'vty' talloc context, that contains lots of items
(memory chunks), is being bound to an application's one,
so it becomes hard to read the last.
Let's do not bind the 'vty' context automatically, until some
common talloc context export policy is implemented.
Change-Id: I9cb6ce9f24dbae400029e2d9f9c933fbfb16248f
The 'show online-help' produces XML output with <node id="..."> ids. We
reference those from the osmo-gsm-manuals.
Instead of numeric IDs coming from internal code, rather use a human-readable
node ID -- referencing id='config-msc' is much easier than referencing id='23'.
Add a char name[] to struct cmd_node, to hold this name. This may be provided
upon struct definition.
Since callers of the VTY API so far don't have a name yet, we would need to add
names everywhere to get meaningful node IDs. There is a way to get node ID
names without touching dependent code:
My first idea was to find out which command entered the node, i.e. command
'msc' enters the MSC_NODE. But it is impossible to derive which command entered
which node from data structs, it's hidden in the vty command definition.
But in fact all (TM) known API callers indeed provide a prompt string that
contains a logical and human readable string name. Thus, if the name is unset
in the struct, parse the prompt string and strip all "weird" characters to
obtain a node name from that. We can still set names later on, but for now will
have meaningful node IDs (e.g. 'config-msc' from '%s(config-msc)# ') without
touching any dependent code.
When VTY nodes get identical node names, which is quite possible, the XML
export de-dups these by appending _2, _3,... suffixes. The first occurence is
called e.g. 'name', the second 'name_2', then 'name_3', and so forth.
If a node has no name (even after parsing the prompt), it will be named merely
by the suffix. The first empty node will become id='_1', then '_2', '_3', and
so forth. This happens for nodes like VIEW_NODE or AUTH_NODE.
If this is merged, we need to adjust the references in osmo-gsm-manuals.git.
This can happen in our own time though, because we manually create the vty
reference xml and copy it to the osmo-gsm-manuals.git and then update the
references from the vty_additions.xml. This anyway has to happen because
currently the references tend to be hopelessly out of sync anyway, placing
comments at wildly unrelated VTY commands.
Change-Id: I8fa555570268b231c5e01727c661da92fad265de
The 'show online-help' produces XML output with <node id="..."> ids. We
reference those from the osmo-gsm-manuals, but until now, these ids fall out of
sync when the amount of VTY nodes changes.
Change these ids to use the internal node ID constant (as in enum bsc_vty_node)
instead of a simple counter.
If this is merged, we need to adjust the references in osmo-gsm-manuals.git.
Change-Id: Ib07fb9d9106e19f5be6539493e82b5d5991f8bc2
The recent exit-by-indent patch breaks a VTY case where a node is entered but
directly followed by a sibling or ancestor without listing any child nodes.
Regression introduced by I24cbb3f6de111f2d31110c3c484c066f1153aac9.
An example is a common usage in osmo-bts, where 'phy N' / 'instance N' is a
parent node that is commonly left empty:
phy 0
instance 0
bts 0
band 1800
Before this patch, this case produces the error:
There is no such command.
Error occurred during reading the below line:
bts 0
Fix indentation parsing logic in command.c to accomodate this case.
Add a unit test for empty parent node.
Change-Id: Ia0880a17ae55accb092ae8585cc3a1bec9986891
Note: This will break users' config files if they do not use consistent
indenting. (see below for a definition of "consistent".)
When reading VTY commands from a file, use indenting as means to implicitly
exit child nodes. Do not look for commands in the parent node implicitly.
The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the
current node, but succeeds on the parent node. That is the mechanism by which
our VTY config files do not need 'exit' at the end of each child node.
We've hit problems with this in the following scenarios, which will show
improved user experience after this patch:
*) When both a parent and its child node have commands with identical names:
cs7 instace 0
point-code 1.2.3
sccp-address osmo-msc
point-code 0.0.1
If I put the parent's command below the child, it is still interpreted in the
context of the child node:
cs7 instace 0
sccp-address osmo-msc
point-code 0.0.1
point-code 1.2.3
Though the indenting lets me assume I am setting the cs7 instance's global PC
to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the
0.0.1.
*) When a software change moves a VTY command from a child to a parent. Say
'timezone' moved from 'bts' to 'network' level:
network
timezone 1 2
Say a user still has an old config file with 'timezone' on the child level:
network
bts 0
timezone 1 2
trx 0
The user would expect an error message that 'timezone' is invalid on the 'bts'
level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts'
to the 'network' level, and instead says that the 'trx' command does not exist.
Format:
Consistent means that two adjacent indenting lines have the exact
same indenting characters for the common length:
Weird mix if you ask me, but correct and consistent:
ROOT
<space>PARENT
<space><tab><space>CHILD
<space><tab><space><tab><tab>GRANDCHILD
<space><tab><space><tab><tab>GRANDCHILD2
<space>SIBLING
Inconsistent:
ROOT
<space>PARENT
<tab><space>CHILD
<space><space><tab>GRANDCHILD
<space><tab><tab>GRANDCHILD2
<tab>SIBLING
Also, when going back to a parent level, the exact same indenting must be used
as before in that node:
Incorrect:
ROOT
<tab>PARENT
<tab><tab><tab>CHILD
<tab><tab>SIBLING
As not really intended side effect, it is also permitted to indent the entire
file starting from the root level. We could guard against it but there's no
harm:
Correct and consistent:
<tab>ROOT
<tab><tab>PARENT
<tab><tab><tab><tab>CHILD
<tab><tab>SIBLING
Implementation:
Track parent nodes state: whenever a command enters a child node, push a parent
node onto an llist to remember the exact indentation characters used for that
level.
As soon as the first line on a child node is parsed, remember this new
indentation (which must have a longer strlen() than its parent level) to apply
to all remaining child siblings and grandchildren.
If the amount of spaces that indent a following VTY command are less than this
expected indentation, call vty_go_parent() until it matches up.
At any level, if the common length of indentation characters mismatch, abort
parsing in error.
Transitions to child node are spread across VTY implementations and are hard to
change. But transitions to the parent node are all handled by vty_go_parent().
By popping a parent from the list of parents in vty_go_parent(), we can also
detect that a command has changed the node without changing the parent, hence
it must have stepped into a child node, and we can push a parent frame.
The behavior on the interactive telnet VTY remains unchanged.
Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
For interactive telnet VTY, remove the implicit move up to the parent node when
a command did not succeed on the current node level.
When reading config files, this behavior was useful to allow skipping explicit
'exit' commands. (A different patch deals with that.)
In the telnet VTY, this behavior was never necessary. Explicit 'exit' commands
can move to the parent node, and typically uninformed users expect to require
that.
On a telnet VTY, counting indents like for reading config files is not an
option: a user will always type from the first column or may paste some leading
spaces without intended meaning.
After this patch, it is thus no longer possible to paste a complete config
across several node levels directly to a telnet session, unless it contains
'exit' commands.
Change-Id: Id73cba2dd34676bad8a130e9c45e67a272f19588
This is very minor but it annoys every time I see it.
The text: "Error occurred during reading below line:"
is not a complete sentence. The default understanding
in english having left out the article implies
that the error occured reading below [the] specified line, not
that the error occured reading [the] specified line.
That is to say, The message implied that the printed line
was the last successfully parsed line.
Change-Id: Ib4dd135feb9609b14983db5dac321a70267d8f30
* when reading config file (or vty command) ignore "logging level
.. everything" level
* when writing config file, skip "logging level .. everything" level
In both cases print corresponding deprecation warning. The "everything"
level is not working as advertised for quite some time anyway.
This will allow us to gradually deprecate broken "everything" parameter
giving users enough time to update their config files before removing it
entirely.
Change-Id: I73d5c4f238beb88981ad25caa69f64ad6fb7209f
Related: OS#71
Considering the various styles and implications found in the sources, edit
scores of files to follow the same API doc guidelines around the doxygen
grouping and the \file tag.
Many files now show a short description in the generated API doc that was so
far only available as C comment.
The guidelines and reasoning behind it is documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation
In some instances, remove file comments and add to the corresponding group
instead, to be shared among several files (e.g. bitvec).
Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
Especially for short descriptions, it is annoying to have to type \brief for
every single API doc.
Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes
the first sentence of an API doc as the brief description.
Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
It's a pity that even with this patch we still are fare away from having
the whole API documented. However, at least we have a more solid
foundation. Updates not only extend the documentation, but also make
sure it is rendered properly in the doxygen HTML.
Change-Id: I1344bd1a6869fb00de7c1899a8db93bba9bafce3
* remove unused parameter from logging_vty_add_cmds()
* mark log level descriptors static
* change internal static function int check_log_to_target() to more
appropriate bool should_log_to_target()
* deprecate log_vty_command_*() from public API as it should only be
used by logging_vty_add_cmds()
Change-Id: I0e9ddd7ba3ce211302d99a3494eb408907a2916e
Related: OS#71
My recent logging patch was merged to master a bit too soon. Accomodate the
request for naming that matches the general "LOG" prefix instead of "LOGGING".
libosmocore will not be backwards-compatible with the few commits from
change-id I5c343630020f4b108099696fd96c2111614c8067 up to this one. This and
following commits are backwards compatible with those before that short window.
See also:
* openbsc change-id Ib2ec5e4884aa90f48051ee2f832af557aa525991
* osmo-pcu change-id I4db4a668f2be07f3d55f848d38d1b490d8a7a685
Change-Id: I424fe3f12ea620338902b2bb8230544bde3f1a93
It is too easy for calling code to use the same filter and context indexes for
different filters and structs. For example, openbsc's IMSI filter and libgb's
GPRS_BVC filter both fall on index 1 even though there are plenty more indexes
to choose from. To alleviate this, have one central definition here, sort of
like ports.h does for VTY and CTRL port numbers.
Add static asserts to make sure the indexes fit in the available array and bit
mask space.
Calling code like openbsc.git and osmo-pcu need adjustments and/or should move
to using these enum values instead of their local definitions.
Taking this opportunity to also prepare for a split of struct gsm_subscriber in
openbsc into bsc_subsciber and vlr_subscriber with appropriate separate filter
index constants for both subscriber types.
Include previous LOG_FILTER_ALL in the LOGGING_FILTER_* enum, and replace its
use by (1 << LOGGING_FILTER_ALL).
Change-Id: I5c343630020f4b108099696fd96c2111614c8067
When the caller installs two identical commands at a given VTY node, the
result is that neither of the two commands can ever be executed: The VTY
would always complain about "Ambiguous command.". Let's fail fast at
program start when two identical commands are intalled.
Change-Id: I85ff4640ebb3d8b75a6a9ab5d2f668edb5b7189e
* update debian/changelog
* update TODO-RELEASE
* add comments to Makefile.am and TODO-RELEASE to simplify the process
in future
* add link to libtool docs to Makefile.am to simplify LIBVERSION
maintenance
Related: OS#1861
Change-Id: I22c257e357f597519120232d742d6a61289db021
Add missing doc string for the HOSTNAME arg.
Added in commit aa00f99be2, this breaks the VTY
tests for openbsc and hence breaks our jenkins build jobs.
Change-Id: I734b22c950242541322e902887bf779c14ba10fd
This target wraps the to-be-logged string (With metadata) into a GSMTAP
packet and sends it to the configured destination address.
Change-Id: I9a7e72b8c9c6f6f2d76d1ea2332dcdee12394625
Without this patch the vty command show logging vty will cause a segfault if
not all elements of the log_categories array are defined.
Ticket: OW#3053
Sponsored-by: On-Waves ehf
Change-Id: Ieeba649c3bde6c9376d8e32b00b92beb37c08ef2
add [options=header] to every table header
vty/show asciidoc: rename reference field into "Reference"
vty/show asciidoc: capilize table header field names
Change-Id: Ie991f4db77a60afb86a2a0b35c137586527f6228
`show stats` shows (null) for osmocom_counters when
description is null.
OpenBSC> show stats
Ungrouped counters:
(null): 4
Change-Id: I553b88a6fca688924b1f2b49e8cb17e90f057bb1
Log 'telnet at 1.2.3.4 5678' from telnet_init*. All callers can now drop any
extra 'VTY at 1.2.3.4 5678' logging.
Change-Id: I1da7b9076311d9458caea732fc0daace6533a3fd
VTY documentations strings follow a certain structure, and we need to
follow that to make the interactive help work.
Change-Id: I0bb0bda68dbbf9995338ec555ff99d73a223162c
Reviewed-on: https://gerrit.osmocom.org/276
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Tested-by: Harald Welte <laforge@gnumonks.org>
For each counter group a ascii doc table is generated
containing all single counter with a reference to a section to
add additional information to the counter
Change-Id: Ia8af883167e5ee631059299b107ea83c8bbffdfb
Reviewed-on: https://gerrit.osmocom.org/70
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Tested-by: Harald Welte <laforge@gnumonks.org>
Add VTY command
line vty
bind A.B.C.D
The command merely stores the configured IP-address, which can then be used by
the calling main program to set the telnet port of the VTY line. (Commits in
openbsc and osmo-iuh will follow up on this.)
Add function vty_get_bind_addr() to publish the address in the vty.h API.
Add static vty_bind_addr to store.
For allocation/freeing reasons, a NULL address defaults to 127.0.0.1.
BTW, I decided against allowing keywords 'any' and 'localhost' in place of an
actual IP address to make sure a written config is always identical to the
parsed config.
'\0' gets translated to zero but the argument to vector_set is
a pointer and it gets converted to a pointer.
vty.c:985:21: warning: expression which evaluates to zero treated as a null pointer constant of type
'void *' [-Wnon-literal-null-conversion]
vector_set(vline, '\0');
^~~~
vty.c:1095:21: warning: expression which evaluates to zero treated as a null pointer constant of type
'void *' [-Wnon-literal-null-conversion]
vector_set(vline, '\0');
^~~~
vty.c:1097:21: warning: expression which evaluates to zero treated as a null pointer constant of type
'void *' [-Wnon-literal-null-conversion]
vector_set(vline, '\0');
^~~~
Shipping our own private copy of talloc was a good idea in 2008,
when it was not readily available on most target platforms. Today,
the situation is quite different, as it is a standard library on
major Linux distributions.
Currently there is only the 'show stats' command which shows all
counter and stat_item values. This can lead to many lines of output
if there are per-subscriber rate counters.
The new command added by this commit allows it to only show groups of
a certain level (class_id), similar to the 'level' configuration
command for stats reporter.
The new command is
show stats level (global|peer|subscriber)
Sponsored-by: On-Waves ehf
For the atoi we need to pass the val as a string. This means
we need to write "0" which then gets parsed to 0.
[src/vty/stats_vty.c:90]: (error) Possible null pointer dereference: val
This commit adds class_id fields to the rate_ctr and stat_item group
descriptions. The stats reporter code is extended to only process
groups whose class_id does not exceed a per reporter max_class level.
If the class_id is not set, the code assumes 'global' for groups with
idx == 0 and 'subscriber' otherwise.
The following vty command is added to config-stats:
level (global|peer|subscriber) Set the maximum group level
Sponsored-by: On-Waves ehf
Harald Welte
Pau Espin
Neels Hofmeyr
Keith Whyte
Neels Hofmeyr