-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib: preparations for RFC5424 syslog support #8656
lib: preparations for RFC5424 syslog support #8656
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution to FRR!
Click for style suggestions
To apply these suggestions:
curl -s https://gist.githubusercontent.com/polychaeta/ae133430b149492ef91dc92adbac8588/raw/1d2f042d82891b40166b1d141cb4c2bb9e57d55e/cr_8656_1620675351.diff | git apply
diff --git a/lib/log_vty.c b/lib/log_vty.c
index cbb8de897..012ca9cc5 100644
--- a/lib/log_vty.c
+++ b/lib/log_vty.c
@@ -596,13 +596,8 @@ DEFUN (no_config_log_filterfile,
return CMD_SUCCESS;
}
-DEFPY (log_filter,
- log_filter_cmd,
- "[no] log filter-text WORD$filter",
- NO_STR
- "Logging control\n"
- FILTER_LOG_STR
- "String to filter by\n")
+DEFPY(log_filter, log_filter_cmd, "[no] log filter-text WORD$filter",
+ NO_STR "Logging control\n" FILTER_LOG_STR "String to filter by\n")
{
int ret = 0;
@@ -625,24 +620,16 @@ DEFPY (log_filter,
}
/* Clear all log filters */
-DEFPY (log_filter_clear,
- log_filter_clear_cmd,
- "clear log filter-text",
- CLEAR_STR
- "Logging control\n"
- FILTER_LOG_STR)
+DEFPY(log_filter_clear, log_filter_clear_cmd, "clear log filter-text",
+ CLEAR_STR "Logging control\n" FILTER_LOG_STR)
{
zlog_filter_clear();
return CMD_SUCCESS;
}
/* Show log filter */
-DEFPY (show_log_filter,
- show_log_filter_cmd,
- "show logging filter-text",
- SHOW_STR
- "Show current logging configuration\n"
- FILTER_LOG_STR)
+DEFPY(show_log_filter, show_log_filter_cmd, "show logging filter-text",
+ SHOW_STR "Show current logging configuration\n" FILTER_LOG_STR)
{
char log_filters[ZLOG_FILTERS_MAX * (ZLOG_FILTER_LENGTH_MAX + 3)] = "";
int len = 0;
If you are a new contributor to FRR, please see our contributing guidelines.
After making changes, you do not need to create a new PR. You should perform an amend or interactive rebase followed by a force push.
Outdated results 💚Basic BGPD CI results: SUCCESS, 0 tests failed
For details, please contact louberger |
Continuous Integration Result: SUCCESSFULContinuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-18927/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
CLANG Static Analyzer Summary
6 Static Analyzer issues remaining.See details at |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see new clang SA issues that need to be addressed. Other than that I don't have a huge problem with this. Get these cleaned up and I'll get this in
`log-filter WORD` was giving me a serious headache since it also matches `log WORD` due to the way the CLI token handling works. This meant that a mistyped `log something` command would silently be interpreted as a filter string, causing me serious headscratching and WTFs until I figured what was going on. Remove this UX pitfall so noone else falls into it. (Since the command was never saved to config, renaming it shouldn't cause trouble.) [Also I apparently forgot to update the docs when I transferred this over to the new zlog bits...] TODO for a rainy day: since we collect all the CLI commands anyway, we should warn somewhere for "2nd level ambiguous" commands like this. Signed-off-by: David Lamparter <equinox@diac24.net>
... so additional targets can print their state. Signed-off-by: David Lamparter <equinox@diac24.net>
printfrr() recently acquired the capability to record start/end of formatting outputs. Make use of this in the zlog code so logging targets have access to this information. (This also records how long the `[XXXXX-XXXXX][EC 9999999]` prefix was so log targets can choose to skip over it.) Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: David Lamparter <equinox@diac24.net>
This is old-style syslog, used among other things for /dev/log. Signed-off-by: David Lamparter <equinox@diac24.net>
Since the file targets append one anyway, save them some extra work. syslog can use `%.*s` since it's "forced" printf by API anyway. Signed-off-by: David Lamparter <equinox@diac24.net>
glibc removed its pid cache a while back, and grabbing this from TLS is faster than repeatedly calling the kernel... Also use `intmax_t` which is more appropriate for both PID & TID. Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: David Lamparter <equinox@diac24.net>
Might've made a few things too many `static` there. Signed-off-by: David Lamparter <equinox@diac24.net>
*sigh*. It doesn't accept `%m` otherwise. Signed-off-by: David Lamparter <equinox@diac24.net>
ee72f83
to
ca846ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution to FRR!
Click for style suggestions
To apply these suggestions:
curl -s https://gist.githubusercontent.com/polychaeta/223b63e33587456a9fac1ec9531fd1c0/raw/1d2f042d82891b40166b1d141cb4c2bb9e57d55e/cr_8656_1624043182.diff | git apply
diff --git a/lib/log_vty.c b/lib/log_vty.c
index cbb8de897..012ca9cc5 100644
--- a/lib/log_vty.c
+++ b/lib/log_vty.c
@@ -596,13 +596,8 @@ DEFUN (no_config_log_filterfile,
return CMD_SUCCESS;
}
-DEFPY (log_filter,
- log_filter_cmd,
- "[no] log filter-text WORD$filter",
- NO_STR
- "Logging control\n"
- FILTER_LOG_STR
- "String to filter by\n")
+DEFPY(log_filter, log_filter_cmd, "[no] log filter-text WORD$filter",
+ NO_STR "Logging control\n" FILTER_LOG_STR "String to filter by\n")
{
int ret = 0;
@@ -625,24 +620,16 @@ DEFPY (log_filter,
}
/* Clear all log filters */
-DEFPY (log_filter_clear,
- log_filter_clear_cmd,
- "clear log filter-text",
- CLEAR_STR
- "Logging control\n"
- FILTER_LOG_STR)
+DEFPY(log_filter_clear, log_filter_clear_cmd, "clear log filter-text",
+ CLEAR_STR "Logging control\n" FILTER_LOG_STR)
{
zlog_filter_clear();
return CMD_SUCCESS;
}
/* Show log filter */
-DEFPY (show_log_filter,
- show_log_filter_cmd,
- "show logging filter-text",
- SHOW_STR
- "Show current logging configuration\n"
- FILTER_LOG_STR)
+DEFPY(show_log_filter, show_log_filter_cmd, "show logging filter-text",
+ SHOW_STR "Show current logging configuration\n" FILTER_LOG_STR)
{
char log_filters[ZLOG_FILTERS_MAX * (ZLOG_FILTER_LENGTH_MAX + 3)] = "";
int len = 0;
If you are a new contributor to FRR, please see our contributing guidelines.
After making changes, you do not need to create a new PR. You should perform an amend or interactive rebase followed by a force push.
@donaldsharp sorry, missed the clang SA warnings and your note… Should be fixed now, let's see what the CI says about the SA. (Rebased while at it, no conflicts yet but still.) |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-19696/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
|
@donaldsharp should be good to go now. (sidenote: the 2 style warnings from checkpatch are "conflicts" with clang-format ... clang-format wants it one way, checkpatch wants it another way, and they can't be satisfied simultaneously.) |
#8457 2nd edition. Doesn't a reboot always help?
This is all the preparatory commits for the upcoming RFC5424 PR which I'll open in a minute. This is split off because everything here should be ready to go regardless of polishing or adjustments on the RFC5424 bits.