Re: Merging relayfs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tomasz Kłoczko wrote:

On Tue, 12 Jul 2005, Vara Prasad wrote:

Tomasz Kłoczko wrote:

On Tue, 12 Jul 2005, Tom Zanussi wrote:

=?ISO-8859-2?Q?Tomasz_K=B3oczko?= writes:
> On Tue, 12 Jul 2005, Tom Zanussi wrote:
[...]

>
> OK .. "so you can say better is stop flushing buffers on measure which
> wil take day or more" ? :_)
> Some DTrace probes/technik are specialy prepared for long or evel very > long time experiment wich will only prodyce few lines results on end of
> experiment.
> Look at DTrace documentation for speculative tracing:
> http://docs.sun.com/app/docs/doc/817-6223/6mlkidli7?a=view


How do you propose to implement speculative tracing without a buffer to hold the data, when data needs to stay in the kernel for a while before we decide to commit or discard?


Buffering some data inside kernel space and buffering with infrastructure for transfer to user space this are two diffrent things.

kloczek

O.K, looks like you are agreeing that we need a buffering mechanism in the kernel to implement speculative tracing, right. Once we have the buffering mechanism we need to create an efficient API for producers of the data to write to that buffering scheme. To my knowledge there is no such generic buffering mechanism already in the kernel, Relayfs implements that buffering scheme and an efficient API to write to it. Isn't that a good reason to have Relayfs merged?

Once the data in the buffer is decided to be committed you need a mechanism to get that data from the kernel to userspace. If you don't like Relayfs transfer mechanism, what do you suggest using?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux