On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote:
> Now if only I could remember what I talked about after I left the Black
> Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
> button and said "'M' for more beer" ...
I bet in involved 'M' for more markers,
Christoph Hellwig wrote:
> That beein said I wish LTT folks would make a little more progress so
> we could actually include it.
We're working on it. On the topic of revamping LTT, 3 different people
came up with 3 different implementations.
Following your feedback on the patch I sent a few
Christoph Hellwig wrote:
That beein said I wish LTT folks would make a little more progress so
we could actually include it.
We're working on it. On the topic of revamping LTT, 3 different people
came up with 3 different implementations.
Following your feedback on the patch I sent a few weeks
On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote:
Now if only I could remember what I talked about after I left the Black
Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
button and said 'M' for more beer ...
I bet in involved 'M' for more markers, Karim
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> Another vote in favor of relayfs here ...
>
> I am reminded by my good colleagues at SGI that relayfs is a key
> to the Linux Trace Toolkit (LTT), which is in turn an important
> technology for some product(s) on which SGI is
On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
Another vote in favor of relayfs here ...
I am reminded by my good colleagues at SGI that relayfs is a key
to the Linux Trace Toolkit (LTT), which is in turn an important
technology for some product(s) on which SGI is working.
I
Another vote in favor of relayfs here ...
I am reminded by my good colleagues at SGI that relayfs is a key
to the Linux Trace Toolkit (LTT), which is in turn an important
technology for some product(s) on which SGI is working.
It is uses such as this which speak to the value of including
relayfs
Another vote in favor of relayfs here ...
I am reminded by my good colleagues at SGI that relayfs is a key
to the Linux Trace Toolkit (LTT), which is in turn an important
technology for some product(s) on which SGI is working.
It is uses such as this which speak to the value of including
relayfs
Bert wrote:
> the diskstat tools require relayfs
That way might lay the real value of relayfs, as a common
technology basis for specific tools that are developed
and maintained on top of relayfs.
--
I won't rest till it's the best ...
Programmer, Linux
>
> When I'm debugging something requiring detailed tracing, I don't want
> to have to think about whether the tracing tool has the particular
> behaviour, performance, data loss, and other such characteristics
> needed for my immediate needs. It is easier to code up some little
> ad hoc
Steve wrote:
> The reason I would like to see this merged, so kernel hackers don't need
> to constantly write there own logging buffers everytime you need to
> debug a complex area of the kernel.
But I doubt that relayfs, or anything resembling it, will accomplish
this purpose, at least for some
Steve wrote:
The reason I would like to see this merged, so kernel hackers don't need
to constantly write there own logging buffers everytime you need to
debug a complex area of the kernel.
But I doubt that relayfs, or anything resembling it, will accomplish
this purpose, at least for some of
When I'm debugging something requiring detailed tracing, I don't want
to have to think about whether the tracing tool has the particular
behaviour, performance, data loss, and other such characteristics
needed for my immediate needs. It is easier to code up some little
ad hoc mechanism
Bert wrote:
the diskstat tools require relayfs
That way might lay the real value of relayfs, as a common
technology basis for specific tools that are developed
and maintained on top of relayfs.
--
I won't rest till it's the best ...
Programmer, Linux
On Sun, 2005-07-17 at 21:45 +0200, bert hubert wrote:
> On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
>
> > It is racey - in this mode, there's nothing to keep the kernel from
> > writing as much as it wants before the user side has a chance to read
> > any of it. The only way
On Sun, 2005-07-17 at 21:45 +0200, bert hubert wrote:
On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
It is racey - in this mode, there's nothing to keep the kernel from
writing as much as it wants before the user side has a chance to read
any of it. The only way this can be
bert hubert writes:
> On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
>
> > It is racey - in this mode, there's nothing to keep the kernel from
> > writing as much as it wants before the user side has a chance to read
> > any of it. The only way this can be used safely is to
On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
> It is racey - in this mode, there's nothing to keep the kernel from
> writing as much as it wants before the user side has a chance to read
> any of it. The only way this can be used safely is to make sure the
> kernel side isn't
bert hubert writes:
> On Sat, Jul 16, 2005 at 06:13:55PM -0500, Tom Zanussi wrote:
>
> > relayfs itself only provides the buffering and file operations along
> > with the kernel API for clients as documented in
> > Documentation/filesystems/relayfs.txt. Applications still need some
> >
bert hubert writes:
On Sat, Jul 16, 2005 at 06:13:55PM -0500, Tom Zanussi wrote:
relayfs itself only provides the buffering and file operations along
with the kernel API for clients as documented in
Documentation/filesystems/relayfs.txt. Applications still need some
kind of
On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
It is racey - in this mode, there's nothing to keep the kernel from
writing as much as it wants before the user side has a chance to read
any of it. The only way this can be used safely is to make sure the
kernel side isn't writing
bert hubert writes:
On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
It is racey - in this mode, there's nothing to keep the kernel from
writing as much as it wants before the user side has a chance to read
any of it. The only way this can be used safely is to make sure
22 matches
Mail list logo
