lkml.org 
[lkml]   [2005]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.11-rc1-mm1
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.208 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site