Re: 2.6.11-rc1-mm1

[Roman Zippel]

Hi,

On Mon, 17 Jan 2005, Karim Yaghmour wrote:

> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to have an end-of-buffer callback.

There of course has to be some kind of end marker, but that's less 
critical as it's not the active buffer anymore.

> Roman, of all people I've been more than happy to change my stuff following
> your recommendations. Do I have to list how far down relayfs has been
> stripped down?

Sorry, you missunderstood me. At the moment I'm only secondarily 
interested in the API details, primarily I want to work out the details of 
what exactly relayfs/ltt are supposed to do. One main question here I 
can't answer yet, why you insist on multiple relayfs modes.
This is what I basically have in mind for the relay_write function:

	cpu = get_cpu();
	buffer = relay_get_buffer(chan, cpu);
	while(1) {
		offset = local_add_return(buffer->offset, length);
		if (likely(offset + length <= buffer->size))
			break;
		buffer = relay_switch_buffer(chan, buffer, offset);
	}
	memcpy(buffer->data + offset, data, length);
	put_cpu();

ltt_log_event should only be a few lines more (for writing header and 
event data).
What I'd like to know now are the reasons why you need more than this.
It's not the amount of data and any timing requirements have to be done by 
the caller. During processing you either take the events in the order they 
were recorded (often that's good enough) or you sort them which is not 
that difficult.

> You ask what compromises can be found from both sides to obtain a
> single implementation. I have looked at this, and given how
> stripped down it has become, anything less from relayfs will make
> it useless for LTT. IOW, I would have to reimplement a buffering
> scheme within LTT outside of relayfs.

I know you don't want to touch the topic of kernel debugging, but its 
requirements greatly overlap with what you want to do with ltt, e.g. one 
needs very often information about scheduling events as many kernel 
processes rely more and more on kernel threads. The only real requirement 
for kernel debugging is low runtime overhead, which you certainly like to 
have as well. So what exactly are these requirements and why can't there 
be no reasonable alternative?

bye, Roman
-
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/