ions about the
specifics than I could have. My priority was to clarify the basis for
the need being addressed.
Cheers,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
how people how to benefit from such tools
under Android. Joel's present set of patches would obviate this problem.
HTH,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
y operate regardless of which part of the
system id being substituted or replaced.
Cheers,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
kheaders
rm -rf $HOME/headers
mkdir -p $HOME/headers
tar -xvf /proc/kheaders.txz -C $HOME/headers >/dev/null
cd my-kernel-module
make -C $HOME/headers M=$(pwd) modules
rmmod kheaders
Signed-off-by: Joel Fernandes (Google)
Acked-by: Karim Yaghmour
---
Changes since v1:
- removed IKH_EX
his button to work and
incorporate eBPF, the system needs to be able to describe itself.
I like that: "the system needs to be able to describe itself". True.
Cheers,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
ly of kernel images.
There are "too many clicks" involved and someone somewhere will drop the
ball if it's not glued to the kernel in some way shape or form. Any
solution that solves this is one I'd love to hear about.
My $0.02
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
erf_importer.js
> with a bunch 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 "bro
erf_importer.js
> with a bunch 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 &quo
ndors. So it's much likelier that an Androidized
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
Google
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 Ya
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
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
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
from that for
the moment.
--
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.o
.
--
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
ke to see 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-kerne
ry single 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 "unsubscrib
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.
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
- 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
- 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
- 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
- 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
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
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
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
#
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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).
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
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.
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
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
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
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
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
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
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
h
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 authoritativ
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
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
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
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
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
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
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]
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]
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
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
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
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
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
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
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
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,
>>+
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
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
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
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
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
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
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 str
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
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 str
1 - 100 of 205 matches
Mail list logo
