Re: [RFC] New kernel-message logging API
- From: Michael Holzheu <holzheu@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 24 Sep 2007 11:22:22 +0200
Hi Vegard,
On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote:
After recent discussions on LKML and a general dissatisfaction at the
current printk() kernel-message logging interface, I've decided to
write down some of the ideas for a better system.
Good luck :-)
[snip]
Example: {
struct kprint_buffer buf;
kprint_buffer_init(&buf, KPRINT_DEBUG);
kprint_buffer(&buf, "Stack trace:");
while(unwind_stack()) {
kprint_buffer(&buf, "%p %s", address, symbol);
}
kprint_buffer_flush(&buf);
}
Together with the idea of not allowing multiple lines in the kprint_xxx
functions, that would go with our approach having message numbers to
identify a message. Multiple lines are combined explicitly to one
message. I think it is a good idea to be able to identify, which lines
of a message belong together.
[snip]
With such a modular interface, message attributes (for example the
current time) and arguments can be recorded separately from the actual
format string, instead of written formatted to a ring buffer as a
sequence of characters. Parameters would be formatted to their own
strings (regardless of the original type) and saved in an array.
Example: {
struct kprint_message {
const char *format;
unsigned int argc;
char **argv;
#ifdef KPRINT_TIMESTAMP
unsigned long long timestamp;
#endif
#ifndef KPRINT_LOCATION
const char *file;
unsigned int line;
const char *function;
#endif
};
}
[snip]
The message entry and a message's arguments are kept separately. Most
likely, there will be a huge number of tiny allocations. I am not sure
how well this is handled in the kernel. Or we could try to merge the
allocation of the struct kprint_message and its arguments into a
single allocation by looking at the arguments before they're
formatted. After all, the arguments cannot exist without the message
or vice versa. Alternatively, a statically-sized ring buffer of struct
kprint_message objects could be used, and then only arguments would
need to be allocated dynamically. Either way, I think it should be
possible to come up with a fairly memory-efficient system even for
this method of storing the kernel log.
Would be nice to have some code here. How do you want to implement that?
You have to allocate / preallocate memory for the argv array. Something
like:
kprint_err(const char* fmt, ...)
{
va_list ap;
struct kprint_message *msg;
msg = &message_arry[current];
va_start(ap, fmt);
msg->argv = kmalloc(sizeof(long) * argc, GFP_KERNEL);
...
for (i = 0; i < argc, i++) {
msg->argv[i] = va_arg(ap, long);
}
If you do it like that, you can't support "%s", since then you would
store only the pointer and not the whole string. I think, that we can't
live without %s.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [RFC] New kernel-message logging API
- From: Joe Perches
- Re: [RFC] New kernel-message logging API
- References:
- [RFC] New kernel-message logging API
- From: Vegard Nossum
- [RFC] New kernel-message logging API
- Prev by Date: [PATCH] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
- Next by Date: Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...
- Previous by thread: Re: [RFC] New kernel-message logging API
- Next by thread: Re: [RFC] New kernel-message logging API
- Index(es):
Relevant Pages
|