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
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory
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
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 be
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
But how does relayfs organize the namespace then? What if I have
multiple channels per CPU, each for a different type of data, will
all channels for the same CPU be under the same directory or will
each type of data have its own directory with
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
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 be
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
> I should have avoided earlier confusing the use of a certain type of
> relayfs channel for a given purpose (i.e. LTT should not necessarily
> depend on the managed mode.) I believe that there is a need for
> more than one mode in relayfs
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
I should have avoided earlier confusing the use of a certain type of
relayfs channel for a given purpose (i.e. LTT should not necessarily
depend on the managed mode.) I believe that there is a need for
more than one mode in relayfs independently
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
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
[ 3rd try. Apologies to Karim, Thomas, and Roman, who apparently also
received my previous attempts. For some reason, one of my upstream
DNS servers decided to send me highly bogus MX records. ]
Karim Yaghmour wrote:
> Might I add that this is part of the problem ... No personal
> offence
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
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
On Wed, Jan 19, 2005 at 11:06:10PM +, Marcos D. Marado Torres wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 14 Jan 2005, Barry K. Nathan wrote:
>
> >This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
> >users) "ACPI shutdown bug" -- poweroff hangs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Jan 2005, Barry K. Nathan wrote:
This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
users) "ACPI shutdown bug" -- poweroff hangs instead of actually turning
the computer off, on some computers. Here's the RH Bugzilla report
Alle 13:42, mercoledì 19 gennaio 2005, bert hubert ha scritto:
> On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> > vmstat under load is the following, and config.gz attached. Of course I
> > can provide any other needed detail; many thanks for any hint.
>
> Looks mightily like DMA
Werner Almesberger wrote:
>>From all I've heard and seen of LTT (and I have to admit that most
> of it comes from reading this thread, not from reading the code),
Might I add that this is part of the problem ... No personal
offence intended, but there's been _A LOT_ of things said about
LTT that
Christoph Hellwig wrote:
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> vmstat under load is the following, and config.gz attached. Of course I can
> provide any other needed detail; many thanks for any hint.
Looks mightily like DMA is not on, even though you compiled the PIIX driver
in, which lists
>
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
> One of the things that uses these functions to read from a channel
> from within the kernel is the relayfs code that implements read(2), so
> taking them away means you wouldn't be able to use read() on a relayfs
> file.
Removing them
On Sun, Jan 16, 2005 at 02:30:33PM -0600, Tom Zanussi wrote:
> This would allow an application to write trace events of its own to a
> trace stream for instance.
I don't think this is a good idea. Userspace could aswell easily write
its trace into shared memory segments.
> Also, I added a
On Sun, Jan 16, 2005 at 02:30:33PM -0600, Tom Zanussi wrote:
This would allow an application to write trace events of its own to a
trace stream for instance.
I don't think this is a good idea. Userspace could aswell easily write
its trace into shared memory segments.
Also, I added a
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
file.
Removing them
On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
vmstat under load is the following, and config.gz attached. Of course I can
provide any other needed detail; many thanks for any hint.
Looks mightily like DMA is not on, even though you compiled the PIIX driver
in, which lists
Christoph Hellwig wrote:
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
Werner Almesberger wrote:
From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
Might I add that this is part of the problem ... No personal
offence intended, but there's been _A LOT_ of things said about
LTT that
Alle 13:42, mercoledì 19 gennaio 2005, bert hubert ha scritto:
On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
vmstat under load is the following, and config.gz attached. Of course I
can provide any other needed detail; many thanks for any hint.
Looks mightily like DMA is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Jan 2005, Barry K. Nathan wrote:
This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
users) ACPI shutdown bug -- poweroff hangs instead of actually turning
the computer off, on some computers. Here's the RH Bugzilla report
On Wed, Jan 19, 2005 at 11:06:10PM +, Marcos D. Marado Torres wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Jan 2005, Barry K. Nathan wrote:
This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
users) ACPI shutdown bug -- poweroff hangs instead of
>From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
I have the impression that it may try to be a bit too specialized,
and thus might miss opportunities for synergy.
You must be getting tired of people trying to
Karim Yaghmour writes:
>
> 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:
> >
> >
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
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to
Hi,
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
> Hello,
>
> I?m a developer of yet another kernel tracer, LKST. I and co-developers
> are very glad to hear that LTT was merged into -mm tree and to talk
> about the kernel tracer on this ML. Because we think that the kernel
>
Hello,
I’m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event tracer is useful to debug Linux systems, and to improve the kernel
On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote:
> 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
On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote:
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
Hello,
Im a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event tracer is useful to debug Linux systems, and to improve the kernel
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event
Hi,
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
With that said, I hope we've agreed that we'll have a callback for
letting relayfs clients know that they need to write the begining of
the buffer event. There won't be any associated reserve. Conversly,
I hope it is not too much to ask to have
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 writes:
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:
From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
I have the impression that it may try to be a bit too specialized,
and thus might miss opportunities for synergy.
You must be getting tired of people trying to
Karim Yaghmour writes:
>
> 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
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
Hi,
I'm very much a newbie to all of this, but I'm finding this
discussion fairly interesting.
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
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
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> a) create indexes, b) reorder events, and likely c) have to rewrite
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
J.A. Magallon wrote:
This does not patch against -mm1. -mm1 looks like a mix of plain 2.6.10
and your code.
Could you revamp it against -mm1, please ? I looked at it but seems out
of my understanding...
My patch replaces the one in -mm1.
Just revert the waiting-10s-... patch that is in
On Mon, 2005-01-17 at 18:41 -0500, Karim Yaghmour wrote:
> 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
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour 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
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
On Mon, 2005-01-17 at 17:42 -0500, Robert Wisniewski wrote:
> I believe (and Karim can correct me if I'm wrong) the idea is to have
> groups of events that can be disabled and enabled via a one word mask. No
> checking multiple variables, no #ifdefing, something very streamlined. By
> userspace
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
On 2005.01.16, Daniel Drake wrote:
> Hi,
>
> Joseph Fannin wrote:
> > On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
> >
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> >>waiting-10s-before-mounting-root-filesystem.patch
>
On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
> 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
n <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL
On Mon, 2005-01-17 at 15:32 -0500, Karim Yaghmour wrote:
> You're either on crack or I don't know how to read english. Here's what
> you said:
Maybe you should read your own comment about ad-hominem attacks earlier
in this thread and consider if it might apply to you.
I know, what I have said. I
On Fri, Jan 14, 2005 at 06:58:10PM -0800, William Lee Irwin III wrote:
> No idea what hit me just yet. x86-64 doesn't boot. Still going through
> the various architectures. The same system (including the initrd FPOS
> bullcrap, though, of course, I'm using an initrd built just for this
> kernel)
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
Hi, Andrew Morton schrub am Fri, 14 Jan 2005 10:35:34 -0800:
> What filesystem(s) do you use, and why?
sshfs (best idea for file access through firewalls).
gmailfs (best free off-site backup facility).
Will use encfs as soon as FUSE is in mainline
(I'm using cryptoloop now, but that's not
Karim Yaghmour writes:
>
> Hello Roman,
>
>
> What we are dropping for later review: read/write semantics from
> user-space. It has to be understood that we believe that this is
> a major drawback. For one thing, you won't be able to do something
> like:
> $ cat /relayfs/xchg/my-file >
On Mon, Jan 17, 2005 at 10:48:52AM -0500, Robert Wisniewski wrote:
> Wow - disabling interrupts is handfuls to tens of cycles, so that means
> some architectures take thousands of cycles to do atomic operations. Then
> I would definitely agree we should not be using atomic operations on those,
>
Arjan van de Ven writes:
> On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
>
> > :-) - as above. Furthermore, it seems that reducing the places where
> > interrupts are disabled would be a good thing?
>
> depends at the price. On several cpus, disabling interupts is hundreds
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> > You can make it even simpler by dropping this completely. Every buffer is
> > simply a list of events and you can let ltt write periodically a timer
> > event. In userspace you can randomly seek at buffer boundaries and search
> > for the
On Sun, 2005-01-16 at 21:24 -0500, Karim Yaghmour wrote:
> > Sorting out disabled events in the hot path and moving the if
> > (pid/gid/grp) whatever stuff into userspace postprocessing is not an
> > alien request.
>
> It is. Have you even read what I suggested to change in my other mail:
> if
On Sun, 2005-01-16 at 20:54 -0500, 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
>
> LTT currently does 1, 2 & 3.
On Sun, 2005-01-16 at 20:54 -0500, 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
LTT currently does 1, 2 3. Clearly, as in
On Sun, 2005-01-16 at 21:24 -0500, Karim Yaghmour wrote:
Sorting out disabled events in the hot path and moving the if
(pid/gid/grp) whatever stuff into userspace postprocessing is not an
alien request.
It is. Have you even read what I suggested to change in my other mail:
if
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
You can make it even simpler by dropping this completely. Every buffer is
simply a list of events and you can let ltt write periodically a timer
event. In userspace you can randomly seek at buffer boundaries and search
for the timer
Arjan van de Ven writes:
On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
:-) - as above. Furthermore, it seems that reducing the places where
interrupts are disabled would be a good thing?
depends at the price. On several cpus, disabling interupts is hundreds
of
On Mon, Jan 17, 2005 at 10:48:52AM -0500, Robert Wisniewski wrote:
Wow - disabling interrupts is handfuls to tens of cycles, so that means
some architectures take thousands of cycles to do atomic operations. Then
I would definitely agree we should not be using atomic operations on those,
Karim Yaghmour writes:
Hello Roman,
What we are dropping for later review: read/write semantics from
user-space. It has to be understood that we believe that this is
a major drawback. For one thing, you won't be able to do something
like:
$ cat /relayfs/xchg/my-file
Hi, Andrew Morton schrub am Fri, 14 Jan 2005 10:35:34 -0800:
What filesystem(s) do you use, and why?
sshfs (best idea for file access through firewalls).
gmailfs (best free off-site backup facility).
Will use encfs as soon as FUSE is in mainline
(I'm using cryptoloop now, but that's not
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
On Fri, Jan 14, 2005 at 06:58:10PM -0800, William Lee Irwin III wrote:
No idea what hit me just yet. x86-64 doesn't boot. Still going through
the various architectures. The same system (including the initrd FPOS
bullcrap, though, of course, I'm using an initrd built just for this
kernel) boots
On Mon, 2005-01-17 at 15:32 -0500, Karim Yaghmour wrote:
You're either on crack or I don't know how to read english. Here's what
you said:
Maybe you should read your own comment about ad-hominem attacks earlier
in this thread and consider if it might apply to you.
I know, what I have said. I
n [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
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
On 2005.01.16, Daniel Drake wrote:
Hi,
Joseph Fannin wrote:
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting
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
On Mon, 2005-01-17 at 17:42 -0500, Robert Wisniewski wrote:
I believe (and Karim can correct me if I'm wrong) the idea is to have
groups of events that can be disabled and enabled via a one word mask. No
checking multiple variables, no #ifdefing, something very streamlined. By
userspace I
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
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour 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
1 - 100 of 183 matches
Mail list logo
