ipt_LOG and friends. Question

[Joakim Axelsson]

I am writing myself a new/better ipt_LOG (or xt_LOG). I won't go into why i
am not using ULOG. Its not the point here so.

Is there some special reason to call printk() in the logging code for every
little piece of info. This gives a problem when using "Networking console
logging support" (the netconsole module). Each printk will result in one
line of log (one UDP-packet) leaving the reiceving syslog-daemon on another
machine puting several lines of log for each log.

Also, there is a lock so only one can enter the dump_packet -code in order
to not get two packets logging at the same time. Locks are costly.

What so wrong with using a buffer of say around 1024 chars and a strcat-like
function (but smarter) keeping track of where to write next and not buffer
overflowing. And finally printk().

Like:

#define MAXLEN 1016
struct log_buffer {
	char log[MAXLEN]
	char *ptr
}

/* sizeof(log_buffer) <= 1024, even in 64bits */

int printlog(struct log_buffer *b, char *fmt, ...) 
{
	if (b->ptr + bytes need writing > log + MAXLEN) {
		return error
	else {
		add string to b->ptr
		update b->ptr for next call
	}
}


This struct should need allocated on stack. This might be a bad idea steal
that much memory on stack? So we could GPF_ATOMIC allocate it or use one
global and lock it. I think however that locking is more expensive than
memory alloc. 

Any problems with this? Have i missed something? Any good reason for calling
printk() that many times?

--
Joakim Axelsson