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
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe
AQ at http://www.tux.org/lkml/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-
To unsubs
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
===
Karim Yaghmour
[EMAIL
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
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
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
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
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
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
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
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
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
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
--
===
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
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
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
.)
===
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
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
://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
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Mathieu Desnoyers wrote:
The main goal of this config option is for embedded systems which doesn't support live
code modification. Maybe we can put that under embedded sytems menu ?
Not sure whether you had had other feedback on
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Hello Mathieu,
Mathieu Desnoyers wrote:
Yes, that was indeed the first way I implemented it, as a disable option. One of the
main thing we have to figure out before I modify this is if we want to have the generic version of
markers
- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED
Mathieu Desnoyers wrote:
The problem with your proposal, I guess, is that people will have to add a
supplementary parameter to the macro.
It is not uncommon to have two slightly versions of macros/functions in the
kernel
Kingsley Cheung wrote:
To solve the problem I applied a patch similar to the one you posted
back in July and it fixed the problem. Could we consider putting this
patch into relayfs? Its similar to the one posted in July 2004, except
it also moves clear_readers() before INIT_WORK in
Tomasz Kłoczko wrote:
*NOT using realyfs* if it is not neccessary for possibly big amout
of feactures future KProbes IMO in this case is *fundamental*.
To time where this base not requiring relayfs feactures will not be
integrated in kernel code better IMO will be stop merging relayfs.
Roman Zippel wrote:
The point is to design a simple and flexible relayfs layer, which means
not every possible function has to be done in the relayfs layer, as long
it's flexible enough to build additional functionality on top of it (for
which it can again provide some library functions).
I have a usb-attached HD that I use from time to time. When it's connected
to my desktop through a hub it works flawlessly. When connected to my Dell
D600 Laptop, however, it sometimes randomly exhibits a loud click (as if the
heads went berzerk) and the device goes unrecognized (i.e. the USB
Greg KH wrote:
Ugh, you have a bad device or power supply, or aren't giving it enough
power to drive the thing. Nothing we can do in Linux for that, sorry.
Buy a wall-powered usb hub, that usually helps.
I have one. I naively thought I could just plug the drive directly to the
laptop without
Tom Zanussi wrote:
- removed the deliver() callback
- removed the relay_commit() function
This breaks LTT. Any reason why this needed to be removed? In the end,
the code will just end up being duplicated in ltt and all other users.
IOW, this is not some potential future use, but something
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
Alistair John Strachan wrote:
You can get special USB cables that link two USB ports' 5Vs together in
parallel, which seems to help supply the necessary current; after the HD has
spun up you can remove the second dummy USB connector (my laptop only has
two USB ports and I require the
Tom Zanussi wrote:
In userspace, the sub-buffer reading loop looks at the commit value in
the sub-buffer, and if it matches (sub-buffer size - padding), the
buffer has been completely written and can be saved, otherwise it's
not yet complete and is checked again the next time around. This
Brad Tilley wrote:
Is there an easy way to make a running kernel display how it has been
patched from vanilla? Probably not, but I thought I'd ask.
This issue does come up every so often. If you look in the archives you
should find some info about this, including a patch if my memory is
Christoph Hellwig wrote:
We're not gonna add hooks to the kernel so you can copile the same
horrible code you had before against it out of tree. Do a sane demux
and submit it.
If I just wanted hooks, I would have submitted a patch that did just
that, without any logging function. The code
Missing attachment herein included.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
L M B E N C H 2 . 0 S U M M A R Y
Paul Rolland wrote:
mmap | 794us | 654us (+18%) | 822us (+4%)
You mean -18%, not +18% I think.
Doh ... too many numbers flying around ... yes, -18% :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and
Ingo Molnar wrote:
yeah, they definitely have helped, and thanks for this round of testing
too! I'll explain the recent changes to PREEMPT_RT that resulted in
these speedups in another mail.
Great, I'm very much looking forward to it.
Looking at your numbers i realized that the area where
Karim Yaghmour wrote:
I would usually like very much to entertain this further, but we've
really busted all the time slots I had allocated to this work. So at
this time, we really think others should start publishing results.
After all, our results are no more authoritative than those
Can't type right anymore ...
Karim Yaghmour wrote:
BTW, we've also released the latest very of the LRTBF we used to
version
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http
Ingo Molnar wrote:
So why do your ping flood results show such difference? It really is
just another type of interrupt workload and has nothing special in it.
...
are you suggesting this is not really a benchmark but a way to test how
well a particular system withholds against extreme
Andrew Morton wrote:
Still, first let us get a handle on who wants relayfs now and in the future
and for what. Then we can better decide.
We used relayfs for our series of tests on PREEMPT_RT and I-Pipe.
Specifically, we used relayfs buffers to store the timestamps for our
interrupt latency
Greg KH wrote:
What ever happened to exporting the relayfs file ops, and just using
debugfs as your controlling fs instead? As all of the possible users
fall under the debug type of kernel feature, it makes more sense to
confine users to that fs, right?
Actually, like we discussed the last
Greg KH wrote:
Based on the proposed users of this fs, I don't see any. What ones are
you saying are not debug type operations? And yes, I consider LTT a
debug type operation :)
The best part of this, is it gives distros and users a consistant place
to mount the fs, and to know where
Greg KH wrote:
The path/filename dictates how it is used, so putting relayfs type files
in debugfs is just fine. debugfs allows any types of files to be there.
...
New trees in / are not LSB compliant, hence the reason for writing
securityfs to get rid of /selinux and other LSM filesystems
Jan Engelhardt wrote:
Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which
moves a lot of data (depends) to userspace. It uses a ring buffer of fixed
size (set at module load time). Apart from that relayfs could use a dynamic
sized ring buffer, I would not see any
Karim Yaghmour wrote:
What relayfs does, and does very well, is move very large amounts of
data out of the kernel and make them available to user-space with very
little overhead. In the actual case of your tty logger, I've browsed
through the code briefly, and I think that with relayfs you
Jan Engelhardt wrote:
Well, what about things like urandom? It also moves a lot of data and does
nothing else.
Forgive my slowness today, but I don't get the angle here:
- Relayfs is not a replacement for char devices, we've never claimed it
to be.
- Urandom generates a lot of data, and uses
Jan Engelhardt wrote:
Hm? Relayfs does not support a `cat /dev/relay/AChannelName` anymore?
This was a requirement for it to be included.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED]
Roman Zippel wrote:
Ok, great.
BTW I don't really expect the first version to be fully optimized (unless
you want to :) ), but once the basics are right, that can still be added
later.
Agreed. Tom will post updated patches sometime this week. I'll follow up
with the LTT stuff separately as
Andi Kleen wrote:
It's doing a complicated function call which does who knows what in
the logging fast path (I stopped reading after some point)
It definitely is not putc !
I was anticipating some people would have this requirement, and this
is why I introduced the ad-hoc mode. Roman asked
Tom Zanussi wrote:
OK, makes sense to me - I'll get rid of relay_reserve and replace it
with the simple putc write and variant.
Please don't do that. Instead, bring back the ad-hoc mode code, that's
what is was for anyway.
You could just create and log into a separate relayfs channel, if you
Tom Zanussi wrote:
I don't think they need to be mutually exclusive - we could keep
relay_reserve(), but the relay_write() that's currently built on top
of relay_reserve() would use the putc code instead. It's complicating
the API a bit, but if it makes everyone happy...
Actually I think
Greg KH wrote:
On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
+extern void * alloc_rchan_buf(unsigned long size,
+ struct page ***page_array,
+ int *page_count);
+extern void free_rchan_buf(void *buf,
+
Greg KH wrote:
When relayfs is built into the kernel, those symbols are then global to
the whole static kernel.
Please be nice and rename them.
My pleasure :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
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
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
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,
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
:)
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
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
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
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
I'm wondering if anyone's ever done an analysis on the average length
of instructions in an x86-built kernel.
Googling around, I can find references claiming that the average
instruction length on x86 is anywhere from 2.7 to 3.5 bytes, but I
can't find anything studying Linux specifically.
Just
Hello Ingo,
Ingo Oeser wrote:
Just study the output od objdump -d and average the differences
of the first hex number in a line printed, which are followed by a :
Here's a script that does what I was looking for:
#!/bin/bash
# Dissassemble
objdump -d $1 -j .text $2-dissassembled-kernel
#
somewhat
already sent privately. ]
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
ftrace
begin/exit. But possibly starting with some kind of every nth and then
drilling down as the culprit is incrementally singled-out.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
if a divide
and conquer approach (i.e. based on ftrace) wouldn't take the guesswork
out of smart randomization. Just a hunch.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Just wondering if anyone had some pointers on a comparison between the
various logging/buffering mechanisms out there (ring buffer, relay,
lttng buffering, etc.)? Googling was inconclusive.
Anything that has benchmarks/pros/cons would be great.
Thanks,
--
Karim Yaghmour
CEO - Opersys inc
kernel tree from Qualcomm or Intel is closer to what gets really shipped
than the two links above.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
of regex...
including sched_switch: next_prio...
Yes, it does. This is why it's not meant for analyzing large traces.
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
of regex...
including sched_switch: next_prio...
Oh, and you can't use Firefox to view the traces it generates. You can
only use Chrome ... even though the documentation says: ... you can
open the report using a web browser. Which I guess means that browser
= chrome at Google.
--
Karim Yaghmour
CEO
itself to output trace info into trace_marker. And the systrace/atrace
tools made available to app developers need to get access to this
tracing info. So, if Android had tracing disabled, systrace/atrace
wouldn't work.
https://developer.android.com/tools/debugging/systrace.html
--
Karim Yaghmour
CEO
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)
===
1 - 100 of 205 matches
Mail list logo
