2:06 a.m.
Is it possible to remove informational log messages form libqb. I now get:
... [libqb] info: IPC credentials authenticated
I am only interested in critical errors from libqb (pri < LOG_WARNING).
But I want to log informational messages from my application (LOG_INFO).
- Dietmar
5:46 a.m.
On 10/02/12 08:06 +0000, Dietmar Maurer wrote:
Is it possible to remove informational log messages form libqb. I now
get:
... [libqb] info: IPC credentials authenticated
I am only interested in critical errors from libqb (pri < LOG_WARNING).
But I want to log informational messages from my application (LOG_INFO).
There is currently no way to set a target based on a tag. Mainly because
it means adding another configuration function - urg.
I have looked at it once and it looked ugly.
In the short term filter by the file names in lib/*.c
(not ideal I know but it will get the job done).
I'll look at adding an api to solve the problem properly.
-Angus
- Dietmar
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
9:27 a.m.
>But I want to log informational messages from my application
(LOG_INFO).
There is currently no way to set a target based on a tag. Mainly because it means
adding another configuration function - urg.
I have looked at it once and it looked ugly.
In the short term filter by the file names in lib/*.c (not ideal I know but it will get
the job done).
I'll look at adding an api to solve the problem properly.
That would be great .
- Dietmar
12:11 a.m.
In the short term filter by the file names in lib/*.c (not ideal I
know but it will get
the job done).
I am starting to feel stupid now. I can filter messages from ipc_us.c with:
qb_log_filter_ctl(QB_LOG_SYSLOG, QB_LOG_FILTER_ADD,
QB_LOG_FILTER_FILE, "ipc_us.c", LOG_WARNING);
But only if I remove all my other filter (including the default filter).
As soon as I add:
qb_log_filter_ctl(QB_LOG_SYSLOG, QB_LOG_FILTER_ADD, QB_LOG_FILTER_FILE, "*",
LOG_DEBUG);
I get all debug messages from ipc_us.c
Please can you point me to the correct way to do that?
- Dietmar
12:38 a.m.
-----Original Message-----
From: quarterback-devel-bounces(a)lists.fedorahosted.org [mailto:quarterback-
devel-bounces(a)lists.fedorahosted.org] On Behalf Of Dietmar Maurer
Sent: Dienstag, 14. Februar 2012 07:12
To: lib quarterback
Subject: Re: [libqb] howto filter libqb logs
> In the short term filter by the file names in lib/*.c (not ideal I
> know but it will get the job done).
First, it seems that I simply not fully understand the API, so forgive me
if this makes no sense to you.
But I would dump that whole qb_log_filter_ctl() API and simply allow
the user configure a filter callback function.
int32_t qb_log_filter_fn_set(int32_t target, qb_log_filter_fn fn);
IMHO that would we much simpler, because:
- no need to maintain a filter database (list of filters)
- no need to define an API to modify that database
- no need to define the semantics to apply those filters
- full control to the user (not restricted by the semantics of your filter API)
Or what is the advantage of qb_log_filter_ctl()?
- Dietmar
1:58 a.m.
On 14/02/12 06:38 +0000, Dietmar Maurer wrote:
> -----Original Message-----
> From: quarterback-devel-bounces(a)lists.fedorahosted.org [mailto:quarterback-
> devel-bounces(a)lists.fedorahosted.org] On Behalf Of Dietmar Maurer
> Sent: Dienstag, 14. Februar 2012 07:12
> To: lib quarterback
> Subject: Re: [libqb] howto filter libqb logs
>
> > In the short term filter by the file names in lib/*.c (not ideal I
> > know but it will get the job done).
First, it seems that I simply not fully understand the API, so forgive me
if this makes no sense to you.
But I would dump that whole qb_log_filter_ctl() API and simply allow
the user configure a filter callback function.
int32_t qb_log_filter_fn_set(int32_t target, qb_log_filter_fn fn);
IMHO that would we much simpler, because:
- no need to maintain a filter database (list of filters)
- no need to define an API to modify that database
- no need to define the semantics to apply those filters
- full control to the user (not restricted by the semantics of your filter API)
Or what is the advantage of qb_log_filter_ctl()?
Hi Dietmar
I am totally open to that, in fact I did have that at one
point but others wanted a "higher level api".
So to define the behavior:
qb_log_filter_fn_set(target, my_filter_fn);
This will immediatly call my_filter_fn with all currently
know callsites. It and call it later if there are new ones.
If there is a change to your logic in my_filter_fn then
just call qb_log_filter_fn_set() again.
How is that?
I can't drop the other functions now.
-Angus
- Dietmar
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
2:58 a.m.
I am totally open to that, in fact I did have that at one point but
others wanted a
"higher level api".
But what is the advantage of such API?
So to define the behavior:
qb_log_filter_fn_set(target, my_filter_fn);
This will immediatly call my_filter_fn with all currently know callsites.
I am not sure if we talk about the same thing.
That should not call my_filter_fn() immediately. Instead my_filter_fn() should
be called before something gets logged - log is discarded if that function returns
false.
It and call
it later if there are new ones.
If there is a change to your logic in my_filter_fn then just call
qb_log_filter_fn_set() again.
yes.
How is that?
I can't drop the other functions now.
I guess we can have both APIs without problems?
- Dietmar
4:08 a.m.
On 14/02/12 08:58 +0000, Dietmar Maurer wrote:
> I am totally open to that, in fact I did have that at one point
but others wanted a
> "higher level api".
But what is the advantage of such API?
I am not sure one is much better than the other. Just setter vs. callback.
The callback is probably more flexable.
> So to define the behavior:
>
> qb_log_filter_fn_set(target, my_filter_fn);
>
> This will immediatly call my_filter_fn with all currently know callsites.
I am not sure if we talk about the same thing.
That should not call my_filter_fn() immediately. Instead my_filter_fn() should
be called before something gets logged - log is discarded if that function returns false.
I am not sure if you understand the callsites, so I'll explain just in case:
When you log a "struct qb_log_callsite" is created (there is 2 ways this can
happen - I won't go into that now). But for every log you have in your program
there is a "struct qb_log_callsite" instance in the logging system.
When you call filter_ctl() it goes through all those instances and applies
the filter by comparing the filter to the callsite and writing to The
target field.
Then when you log a message the target is already set and it knows what
to do with the message.
The point is to do the expensive "filtering" upfront (so strcmp's etc).
It is faster especially through time critical sections when the same
debug or trace logs are called repeatedly.
> It and call
> it later if there are new ones.
>
> If there is a change to your logic in my_filter_fn then just call
> qb_log_filter_fn_set() again.
yes.
> How is that?
>
> I can't drop the other functions now.
I guess we can have both APIs without problems?
- Dietmar
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
4:17 a.m.
>> qb_log_filter_fn_set(target, my_filter_fn);
>>
>> This will immediatly call my_filter_fn with all currently know callsites.
>
>I am not sure if we talk about the same thing.
>
>That should not call my_filter_fn() immediately. Instead my_filter_fn()
>should be called before something gets logged - log is discarded if that function
returns false.
I am not sure if you understand the callsites, so I'll explain just in case:
When you log a "struct qb_log_callsite" is created (there is 2 ways this can
happen - I won't go into that now). But for every log you have in your program
there is a "struct qb_log_callsite" instance in the logging system.
When you call filter_ctl() it goes through all those instances and applies the filter
by comparing the filter to the callsite and writing to The target field.
Then when you log a message the target is already set and it knows what to do
with the message.
The point is to do the expensive "filtering" upfront (so strcmp's etc).
It is faster especially through time critical sections when the same debug or
trace logs are called repeatedly.
Ah, interesting. So what parameters can we pass to my_filter_fn() ?
I guess we can use tags, filename, and function name?
- Dietmar
6:05 a.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
Signed-off-by: Angus Salkeld <asalkeld(a)redhat.com>
---
examples/simplelog.c | 25 ++++++++++++++++++-------
include/qb/qblog.h | 8 ++++++++
lib/log.c | 26 ++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/examples/simplelog.c b/examples/simplelog.c
index 593dd5c..c0607c2 100644
--- a/examples/simplelog.c
+++ b/examples/simplelog.c
@@ -29,6 +29,8 @@
#define MY_TAG_TWO (1 << 1)
#define MY_TAG_THREE (1 << 2)
+static int32_t _log_priority = LOG_WARNING;
+
static void func_one(void)
{
FILE* fd;
@@ -115,12 +117,23 @@ trace_logger(int32_t t,
fprintf(stderr, "%s\n", output_buffer);
}
+static void
+m_filter(struct qb_log_callsite *cs)
+{
+ if ((cs->priority >= LOG_ALERT &&
+ cs->priority <= _log_priority) &&
+ strcmp(cs->filename, __FILE__) == 0) {
+ qb_bit_set(cs->targets, QB_LOG_STDERR);
+ } else {
+ qb_bit_clear(cs->targets, QB_LOG_STDERR);
+ }
+}
+
int32_t main(int32_t argc, char *argv[])
{
const char *options = "vhtebdf:";
int32_t opt;
int32_t tracer;
- int32_t priority = LOG_WARNING;
int32_t do_stderr = QB_FALSE;
int32_t do_dump_blackbox = QB_FALSE;
char *logfile = NULL;
@@ -144,7 +157,7 @@ int32_t main(int32_t argc, char *argv[])
logfile = optarg;
break;
case 'v':
- priority++;
+ _log_priority++;
break;
case 'h':
default:
@@ -168,10 +181,8 @@ int32_t main(int32_t argc, char *argv[])
tracer = qb_log_custom_open(trace_logger, NULL, NULL, NULL);
if (do_stderr) {
- qb_log_filter_ctl2(QB_LOG_STDERR, QB_LOG_FILTER_ADD,
- QB_LOG_FILTER_FILE, __FILE__,
- LOG_ALERT, QB_MIN(LOG_DEBUG, priority));
- qb_log_format_set(QB_LOG_STDERR, "%4g: %f:%l [%p] %b");
+ qb_log_filter_fn_set(m_filter);
+ qb_log_format_set(QB_LOG_STDERR, "[%p] %4g: %f:%l %b");
qb_log_ctl(QB_LOG_STDERR, QB_LOG_CONF_ENABLED, QB_TRUE);
qb_log_ctl(tracer, QB_LOG_CONF_ENABLED, QB_TRUE);
@@ -190,7 +201,7 @@ int32_t main(int32_t argc, char *argv[])
if (logfile) {
log_fd = qb_log_file_open(logfile);
qb_log_filter_ctl(log_fd, QB_LOG_FILTER_ADD,
- QB_LOG_FILTER_FILE, __FILE__, priority);
+ QB_LOG_FILTER_FILE, __FILE__, _log_priority);
qb_log_format_set(log_fd, "[%N] %t %n() [%p] %b");
qb_log_ctl(log_fd, QB_LOG_CONF_THREADED, do_threaded);
qb_log_ctl(log_fd, QB_LOG_CONF_ENABLED, QB_TRUE);
diff --git a/include/qb/qblog.h b/include/qb/qblog.h
index f1a6305..2d57966 100644
--- a/include/qb/qblog.h
+++ b/include/qb/qblog.h
@@ -237,6 +237,8 @@ struct qb_log_callsite {
uint32_t tags;
} __attribute__((aligned(8)));
+typedef void (*qb_log_filter_fn)(struct qb_log_callsite * cs);
+
/* will be assigned by ld linker magic */
#ifdef QB_HAVE_ATTRIBUTE_SECTION
extern struct qb_log_callsite __start___verbose[];
@@ -462,6 +464,12 @@ int32_t qb_log_filter_ctl2(int32_t value, enum qb_log_filter_conf c,
enum qb_log_filter_type type, const char * text,
uint8_t high_priority, uint8_t low_priority);
+
+/**
+ *
+ */
+int32_t qb_log_filter_fn_set(qb_log_filter_fn fn);
+
/**
* Set the callback to map the 'tags' bit map to a string.
*/
diff --git a/lib/log.c b/lib/log.c
index 867334f..9b9ea9d 100644
--- a/lib/log.c
+++ b/lib/log.c
@@ -43,6 +43,7 @@ static uint32_t conf_active_max = 0;
static int32_t in_logger = QB_FALSE;
static int32_t logger_inited = QB_FALSE;
static pthread_rwlock_t _listlock;
+static qb_log_filter_fn _custom_filter_fn = NULL;
static QB_LIST_DECLARE(tags_head);
static QB_LIST_DECLARE(callsite_sections);
@@ -281,6 +282,9 @@ qb_log_from_external_source_va(const char *function,
} else {
cs->tags = tags;
}
+ if (_custom_filter_fn) {
+ _custom_filter_fn(cs);
+ }
pthread_rwlock_unlock(&_listlock);
}
qb_log_real_va_(cs, ap);
@@ -588,6 +592,28 @@ qb_log_filter_ctl2(int32_t t, enum qb_log_filter_conf c,
}
int32_t
+qb_log_filter_fn_set(qb_log_filter_fn fn)
+{
+ struct callsite_section *sect;
+ struct qb_log_callsite *cs;
+
+ if (!logger_inited) {
+ return -EINVAL;
+ }
+ _custom_filter_fn = fn;
+
+ qb_list_for_each_entry(sect, &callsite_sections, list) {
+ for (cs = sect->start; cs < sect->stop; cs++) {
+ if (cs->lineno == 0) {
+ break;
+ }
+ _custom_filter_fn(cs);
+ }
+ }
+ return 0;
+}
+
+int32_t
qb_log_filter_ctl(int32_t t, enum qb_log_filter_conf c,
enum qb_log_filter_type type,
const char *text, uint8_t priority)
--
1.7.7.6
6:58 a.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
That works without problems :-)
It would be great if you add that feature.
- Dietmar
-----Original Message-----
From: quarterback-devel-bounces(a)lists.fedorahosted.org [mailto:quarterback-
devel-bounces(a)lists.fedorahosted.org] On Behalf Of Angus Salkeld
Sent: Dienstag, 14. Februar 2012 13:06
To: libqb mailing lst
Subject: [libqb] [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
10:22 a.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
Well, thought more about those callsites. and wonder why that works at all.
Because the only qb_log_ call I use is (because of domain/tag conversion):
qb_log_from_external_source()
So there are no callsites involved?! Why does it work anyways?
- Dietmar
-----Original Message-----
From: quarterback-devel-bounces(a)lists.fedorahosted.org [mailto:quarterback-
devel-bounces(a)lists.fedorahosted.org] On Behalf Of Dietmar Maurer
Sent: Dienstag, 14. Februar 2012 13:58
To: lib quarterback
Subject: Re: [libqb] [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
That works without problems :-)
It would be great if you add that feature.
- Dietmar
> -----Original Message-----
> From: quarterback-devel-bounces(a)lists.fedorahosted.org
> [mailto:quarterback- devel-bounces(a)lists.fedorahosted.org] On Behalf
> Of Angus Salkeld
> Sent: Dienstag, 14. Februar 2012 13:06
> To: libqb mailing lst
> Subject: [libqb] [PATCH] LOG: quick demo of possible
> qb_log_filter_fn_set()
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
3:09 p.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
On 14/02/12 16:22 +0000, Dietmar Maurer wrote:
Well, thought more about those callsites. and wonder why that works at
all.
Because the only qb_log_ call I use is (because of domain/tag conversion):
qb_log_from_external_source()
So there are no callsites involved?! Why does it work anyways?
So when using qb_log_from_external_source() they are created
as needed (still only once though - just a bit later).
Only the creation mechanism is different.
- Dietmar
> -----Original Message-----
> From: quarterback-devel-bounces(a)lists.fedorahosted.org [mailto:quarterback-
> devel-bounces(a)lists.fedorahosted.org] On Behalf Of Dietmar Maurer
> Sent: Dienstag, 14. Februar 2012 13:58
> To: lib quarterback
> Subject: Re: [libqb] [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
>
> That works without problems :-)
>
> It would be great if you add that feature.
Cool, well I'll polish it up and add some tests.
-Angus
>
> - Dietmar
>
> > -----Original Message-----
> > From: quarterback-devel-bounces(a)lists.fedorahosted.org
> > [mailto:quarterback- devel-bounces(a)lists.fedorahosted.org] On Behalf
> > Of Angus Salkeld
> > Sent: Dienstag, 14. Februar 2012 13:06
> > To: libqb mailing lst
> > Subject: [libqb] [PATCH] LOG: quick demo of possible
> > qb_log_filter_fn_set()
>
> _______________________________________________
> quarterback-devel mailing list
> quarterback-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/quarterback-devel
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
11:26 p.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
So when using qb_log_from_external_source() they are created as
needed (still
only once though - just a bit later).
Only the creation mechanism is different.
Just found qb_log_dcs_get(). I am slowly starting to understand the code ;-)
One more question. I found the following in qblog.h:
* @param tags This MUST have QB_LOG_EXTERNAL_TAG or'ed in
* so that it gets free'ed.
But what is QB_LOG_EXTERNAL_TAG? I found no define/use in the sources?
- Dietmar
12:09 a.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
On 15/02/12 05:26 +0000, Dietmar Maurer wrote:
> So when using qb_log_from_external_source() they are created as
needed (still
> only once though - just a bit later).
>
> Only the creation mechanism is different.
Just found qb_log_dcs_get(). I am slowly starting to understand the code ;-)
One more question. I found the following in qblog.h:
* @param tags This MUST have QB_LOG_EXTERNAL_TAG or'ed in
* so that it gets free'ed.
But what is QB_LOG_EXTERNAL_TAG? I found no define/use in the sources?
This is just not true, I'll delete this comment now.
Thanks for pointing it out.
-Angus
- Dietmar
_______________________________________________
quarterback-devel mailing list
quarterback-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/quarterback-devel
10:38 a.m.
New subject: [PATCH] LOG: quick demo of possible qb_log_filter_fn_set()
Subject: RE: [libqb] [PATCH] LOG: quick demo of possible
qb_log_filter_fn_set()
Well, thought more about those callsites. and wonder why that works at all.
Because the only qb_log_ call I use is (because of domain/tag conversion):
qb_log_from_external_source()
So there are no callsites involved?! Why does it work anyways?
Ok, the inline docu for qb_log_from_external_source states: "the filtering is done
on each log message"
I guess that explain the behavior.
- Dietmar
4458
days inactive
4463
days old
quarterback-devel@lists.fedorahosted.org
15 comments
2 participants
participants (2)
-
Angus Salkeld -
Dietmar Maurer