Hello Roman,
Roman Zippel wrote:
> Well, let's concentrate for a moment on the last thing and check later
> if and how they fit into relayfs. Since ltt will be first main user, let's
> optimize it for this.
> Also since relayfs is intended for large, fast data transfers, per cpu
> buffers are
Hello Roman,
Roman Zippel wrote:
Well, let's concentrate for a moment on the last thing and check later
if and how they fit into relayfs. Since ltt will be first main user, let's
optimize it for this.
Also since relayfs is intended for large, fast data transfers, per cpu
buffers are
Karim Yaghmour wrote:
This is not good for any client that doesn't know beforehand the exact
size of their data units, as in the case of LTT. If LTT has to use this
code that means we are going to loose performance because we will need to
fill an intermediate data structure which will only
Greg KH wrote:
Are they willing to trade off the performance of LTT to get this? I
thought this was being touted as a when you need to test type of
thing, not a run it all the time type of feature.
The problem is that you never know beforehand when you're going to
get that weird glitch on
OK, I finally come around to answering this ...
Roman Zippel wrote:
> 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
Zach Brown wrote:
> Only briefly. They've always seemed more involved than the sort of
> thing I was after. I'll try and sit down and investigate in more detail.
There's definitely an opportunity for interfacing here. If nothing else,
this clearly shows the interest for the kind of things both
Greg KH wrote:
> Hm, how about this idea for cutting about 500 more lines from the code:
>
> Why not drop the "fs" part of relayfs and just make the code a set of
> struct file_operations. That way you could have "relayfs-like" files in
> any ram based file system that is being used. Then, a
Zach Brown wrote:
> Thoughts? I, for one, am tired of writing throw-away per-cpu tracing
> patches ;)
Have you taken a look at relayfs and ltt?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL
Werner Almesberger wrote:
> - if the probe target is an instruction long enough, replace it with
>a jump or call (that's what I think the kprobes folks are working
>on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything
Werner Almesberger wrote:
- if the probe target is an instruction long enough, replace it with
a jump or call (that's what I think the kprobes folks are working
on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything came
Zach Brown wrote:
Thoughts? I, for one, am tired of writing throw-away per-cpu tracing
patches ;)
Have you taken a look at relayfs and ltt?
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL
Greg KH wrote:
Hm, how about this idea for cutting about 500 more lines from the code:
Why not drop the fs part of relayfs and just make the code a set of
struct file_operations. That way you could have relayfs-like files in
any ram based file system that is being used. Then, a user could
Zach Brown wrote:
Only briefly. They've always seemed more involved than the sort of
thing I was after. I'll try and sit down and investigate in more detail.
There's definitely an opportunity for interfacing here. If nothing else,
this clearly shows the interest for the kind of things both
OK, I finally come around to answering this ...
Roman Zippel wrote:
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
ys a pleasure
talking with you :)
> Karim Yaghmour wrote:
>
>>If you really want to define layers, then there are actually four
>>layers:
>>1- hooking mechanism
>>2- event definition / registration
>>3- event management infrastructure
>>4- transport
:)
Karim Yaghmour wrote:
If you really want to define layers, then there are actually four
layers:
1- hooking mechanism
2- event definition / registration
3- event management infrastructure
4- transport mechanism
For 1, kprobes would seem largely sufficient. In cases where you
don't have
Tom Zanussi wrote:
> I have to disagree. Awhile back, if you remember, I posted a patch to
> the LTT daemon that would monitor the trace stream in real time, and
> process it using an embedded Perl interpreter, no less:
>
> http://marc.theaimsgroup.com/?l=linux-kernel=109405724500237=2
>
> It
Thomas,
Thomas Gleixner wrote:
> Yes, I did already start cleaning
>
> cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
Thomas,
Thomas Gleixner wrote:
Yes, I did already start cleaning
cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
Tom Zanussi wrote:
I have to disagree. Awhile back, if you remember, I posted a patch to
the LTT daemon that would monitor the trace stream in real time, and
process it using an embedded Perl interpreter, no less:
http://marc.theaimsgroup.com/?l=linux-kernelm=109405724500237w=2
It
Aaron Cohen wrote:
> I've got a quick question and I just want to be clear that it
> doesn't have a political agenda behind it.
:)
> Here goes, why can't LTT and/or relayfs, work similar to the way
> syslog does and just fill a buffer (aka ring-buffer or whatever is
> appropriate), while a
Hello Roman,
Roman Zippel wrote:
> Why is so important that it's at the start of the buffer? What's wrong
> with a special event _near_ the start of a buffer?
[snip]
> What gives you the idea, that you can't do this with what I proposed?
> You can still seek freely within the data at buffer
Thomas Gleixner wrote:
> Provide a hook, export it and load your filters as a module, but keep
> the filters out of the mainline kernel code.
Great idea! I will do exactly that.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the
Hello Roman,
Roman Zippel wrote:
> An additional comment about the order of events. What you're doing in
> lockless_reserve is bogus anyway. There is no single correct time to
> write into the event. By artificially synchronizing event order and event
> time you only cheat yourself. You
Thomas Gleixner wrote:
> If we add another hardwired implementation then we do not have said
> benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think
Thomas Gleixner wrote:
> I know, what I have said. I said reduce the filtering to the absolute
> minimum and do the rest in userspace.
You keep adopting the interpretation which best suits you, taking
quotes out of context, and keep repeating things that have already
been answered. There are
Hello Chistoph,
Christoph Hellwig wrote:
> The thing I'm unhappy with is what the code does currently. I haven't
> looked at the code enough nor through about the problem enough to tell
> you what's the right thing to do. Knowing that will involve review of
> the architecture and serious
Hello Roman,
Roman Zippel wrote:
> Periodically can also mean a buffer start call back from relayfs
> (although that would mean the first entry is not guaranteed) or a
> (per cpu) eventcnt from the subsystem. The amount of needed search would
> be limited. The main point is from the relayfs
Thomas Gleixner wrote:
> Thats the point. Adding another hardwired implementation does not give
> us a possibility to solve the hardwired problem of the already available
> stuff.
Well then, like I said before, you know what you need to do:
Thomas Gleixner wrote:
> Sorting out disabled events is the filtering you have to do in kernel
> and you should do it in the hot path or remove the unneccecary
> tracepoints at compiletime.
Do you actually read my replies or do you just grep for something
you can object to? If you care to read
Thomas Gleixner wrote:
Sorting out disabled events is the filtering you have to do in kernel
and you should do it in the hot path or remove the unneccecary
tracepoints at compiletime.
Do you actually read my replies or do you just grep for something
you can object to? If you care to read my
Thomas Gleixner wrote:
Thats the point. Adding another hardwired implementation does not give
us a possibility to solve the hardwired problem of the already available
stuff.
Well then, like I said before, you know what you need to do:
Hello Roman,
Roman Zippel wrote:
Periodically can also mean a buffer start call back from relayfs
(although that would mean the first entry is not guaranteed) or a
(per cpu) eventcnt from the subsystem. The amount of needed search would
be limited. The main point is from the relayfs POV
Hello Chistoph,
Christoph Hellwig wrote:
The thing I'm unhappy with is what the code does currently. I haven't
looked at the code enough nor through about the problem enough to tell
you what's the right thing to do. Knowing that will involve review of
the architecture and serious
Thomas Gleixner wrote:
I know, what I have said. I said reduce the filtering to the absolute
minimum and do the rest in userspace.
You keep adopting the interpretation which best suits you, taking
quotes out of context, and keep repeating things that have already
been answered. There are
Thomas Gleixner wrote:
If we add another hardwired implementation then we do not have said
benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think you
Hello Roman,
Roman Zippel wrote:
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially synchronizing event order and event
time you only cheat yourself. You either
Thomas Gleixner wrote:
Provide a hook, export it and load your filters as a module, but keep
the filters out of the mainline kernel code.
Great idea! I will do exactly that.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the
Hello Roman,
Roman Zippel wrote:
Why is so important that it's at the start of the buffer? What's wrong
with a special event _near_ the start of a buffer?
[snip]
What gives you the idea, that you can't do this with what I proposed?
You can still seek freely within the data at buffer
Aaron Cohen wrote:
I've got a quick question and I just want to be clear that it
doesn't have a political agenda behind it.
:)
Here goes, why can't LTT and/or relayfs, work similar to the way
syslog does and just fill a buffer (aka ring-buffer or whatever is
appropriate), while a
Thomas Gleixner wrote:
> Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
> GB's of data when the 1.42 seconds elapse without an event.
My argument was about being able to browse the amount of data I was
refering to. The hearbeat thing was an asside to Roman as to the
fact
Thomas Gleixner wrote:
> This implies to seperate
>
> - infrastructure
> - event registration
> - transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Hello Roman,
Roman Zippel wrote:
> It seems we first need to specify, what relayfs actually is supposed to
> be. Is it a relaying mechanism for large amount of data from kernel to
> user space or is it a general communication channel between kernel and
> user space? You have to choose one, if
Christoph Hellwig wrote:
> the lockless mode is really just loops around cmpxchg. It's spinlocks
> reinvented poorly.
I beg to differ. You have to use different spinlocks depending on
where you are:
- serving user-space
- bh-derivatives
- irq
lockless is the same primitive regardless of your
Hello Christoph,
Christoph Hellwig wrote:
> Why would you want anything but read access?
Fine, we can put it read-only, we'll drop the "mode" field.
> I think random access is overkill. Keeping the code simple is more
> important and user-space can post-process it.
it's overkill if you're
Hello Christoph,
Christoph Hellwig wrote:
Why would you want anything but read access?
Fine, we can put it read-only, we'll drop the mode field.
I think random access is overkill. Keeping the code simple is more
important and user-space can post-process it.
it's overkill if you're
Christoph Hellwig wrote:
the lockless mode is really just loops around cmpxchg. It's spinlocks
reinvented poorly.
I beg to differ. You have to use different spinlocks depending on
where you are:
- serving user-space
- bh-derivatives
- irq
lockless is the same primitive regardless of your
Hello Roman,
Roman Zippel wrote:
It seems we first need to specify, what relayfs actually is supposed to
be. Is it a relaying mechanism for large amount of data from kernel to
user space or is it a general communication channel between kernel and
user space? You have to choose one, if you
Thomas Gleixner wrote:
This implies to seperate
- infrastructure
- event registration
- transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Currently,
Thomas Gleixner wrote:
Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
GB's of data when the 1.42 seconds elapse without an event.
My argument was about being able to browse the amount of data I was
refering to. The hearbeat thing was an asside to Roman as to the
fact that
Hello Roman,
Roman Zippel wrote:
> It's interesting to read more about ltt's requirements, but I still think
> it's possible to leave this work to the relayfs layer.
Ok, I'm willing to play ball, but can you be a little bit more specific.
> Why not just move the ltt buffer management into
Hello Roman,
Roman Zippel wrote:
> On Sat, 15 Jan 2005, Karim Yaghmour wrote:
>>In addition, and this is a very important issue, quite a few
>>kernel developers mistook LTT for a kernel debugging tool, which
>>it was never meant to be. When, in fact, if you ask those who h
Hello Thomas,
In the interest of avoiding expanding the thread too thin, I'm replying to
both emails in the same time.
Thomas Gleixner wrote:
>>relayfs is a generalized buffering mechanism. Tracing is one application
>>it serves. Check out the web site: "high-speed data-relay filesystem."
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More
Hello Thomas,
In the interest of avoiding expanding the thread too thin, I'm replying to
both emails in the same time.
Thomas Gleixner wrote:
relayfs is a generalized buffering mechanism. Tracing is one application
it serves. Check out the web site: high-speed data-relay filesystem.
Fancy name
Hello Roman,
Roman Zippel wrote:
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
In addition, and this is a very important issue, quite a few
kernel developers mistook LTT for a kernel debugging tool, which
it was never meant to be. When, in fact, if you ask those who have
looked at using
Hello Roman,
Roman Zippel wrote:
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this work to the relayfs layer.
Ok, I'm willing to play ball, but can you be a little bit more specific.
Why not just move the ltt buffer management into
ttp://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "u
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/
--
===
Karim Yaghmour
oolkit (http://www.opersys.com/LTT).
Cheers,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line
://www.opersys.com/LTT).
Cheers,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubs
: 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/
--
===
Karim Yaghmour
ttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsub
en into account.)
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
.)
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
rs,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
rs,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Linux Expert
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
at the "mailing
lists" section of the project's web-site for more detail.
You can find LTT at:
http://www.opersys.com/LTT
Cheers,
Karim Yaghmour
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Li
at the "mailing
lists" section of the project's web-site for more detail.
You can find LTT at:
http://www.opersys.com/LTT
Cheers,
Karim Yaghmour
===
Karim Yaghmour
[EMAIL PROTECTED]
Embedded and Real-Time Li
s since the kernel
doesn't jump in your code, but in the hooks management code
first.
Best regards,
Karim
=======
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, re
mp in your code, but in the hooks management code
first.
Best regards,
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distribut
that this code will certainly crash your machine. It
is an attempt to drive Linux into ring-one, but it is not
functionnal. You've been warned.
Feel free to join in the discussion.
Best regards,
Karim Yaghmour
Karim Yaghmour wrote:
>
> I've put up the following (white) papers out for g
that this code will certainly crash your machine. It
is an attempt to drive Linux into ring-one, but it is not
functionnal. You've been warned.
Feel free to join in the discussion.
Best regards,
Karim Yaghmour
Karim Yaghmour wrote:
I've put up the following (white) papers out for general
hat would be even better. Thanx
>
> Mike
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
is
welcomed to contact me.
KEEP IN MIND that the documents are only a suggested method of
doing things designed to stimulate discussion. There isn't one
line of functionnal code out there (yet).
Best regards,
Karim
===
Karim
is
welcomed to contact me.
KEEP IN MIND that the documents are only a suggested method of
doing things designed to stimulate discussion. There isn't one
line of functionnal code out there (yet).
Best regards,
Karim
===
Karim
the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
x.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
be from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
=======
Karim Yaghmour
[EMAIL PROTECT
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distribut
14 SYSCALL : close; EIP :
0x0804AE41
You can find more info on this custom event logging capability on
LTT's web site at: http://www.opersys.com/LTT
You can find DProbes at:
http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/
Best regards
Karim
===
es at:
http://oss.software.ibm.com/developer/opensource/linux/projects/dprobes/
Best regards
Karim
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To uns
case 1: set_bit(index,
>buttons); break;
---
Karim Yaghmour wrote:
>
> The mac_hid_mouse_emulate_buttons() in drivers/macintosh/mac_hid.c
> which takes care of emulating multiple buttons on a mac doesn't
> seem to be used anywhere. In fact,
Shouldn't this be called upon from the
keyboard and mouse handlers?
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distribut
quot; > /proc/sys/dev/mac_hid/mouse_button_emulation
and there's no effect. Anyone know what this is about?
Thanks.
===
Karim Yaghmour
[EMAIL PROTECTED]
c_hid/mouse_button_emulation
and there's no effect. Anyone know what this is about?
Thanks.
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux k
Shouldn't this be called upon from the
keyboard and mouse handlers?
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distribut
t(index,
list-buttons); break;
-------
Karim Yaghmour wrote:
The mac_hid_mouse_emulate_buttons() in drivers/macintosh/mac_hid.c
which takes care of emulating multiple buttons on a mac doesn't
seem to be used anywhere. In fac
ne "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System
Linux Technology Centre (PISC).
>
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
===
Karim Yaghmour
[EMAIL PROT
T. Would port the code from OS/2
if LTT had a suitable formatting exit for custom events. Any thoughts on
this?
Richard
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mob
ed within a normal trace and, thereafter, be part of trace analysis.
Does this fit your needs?
>
> Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
>
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
Karim
ile: (+44) (0)7768-298183
> IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
leo Centre, Hursley Park, Winchester, SO21 2JN, UK
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distribut
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
Karim
ding LTT,
I invite the interested reader to take a look at the paper I presented last
June at the annual Usenix technical conference:
http://www.opersys.com/LTT/ltt-usenix.ps.gz
And LTT can be found at:
http://www.opersys.com/LTT/
Cheers
==
101 - 200 of 205 matches
Mail list logo
