Re: Merging relayfs?

[Vara Prasad <prasadav@us.ibm.com>]

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?