David Miller wrote:
From: Pavel Machek <[EMAIL PROTECTED]>
Date: Fri, 3 Nov 2006 09:57:12 +0100
Not sure what you are smoking, but "there's unsigned long in *bsd
version, lets rewrite it from scratch" sounds like very bad idea. What
about fixing that one bit you don't like?
I disagree, it's m
Nate Diller wrote:
Indesiciveness has certainly been an issue here, but I remember akpm
and Ulrich both giving concrete suggestions. I was particularly
interested in Andrew's request to explain and justify the differences
between kevent and BSD's kqueue interface. Was there a discussion
that I
On Sun, Nov 05, 2006 at 12:19:33PM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Hi!
>
> On Fri 2006-11-03 12:13:02, Evgeniy Polyakov wrote:
> > On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED])
> > wrote:
> > > > So, kqueue API and structures can not be usd in Linux.
Hi!
On Fri 2006-11-03 12:13:02, Evgeniy Polyakov wrote:
> On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED])
> wrote:
> > > So, kqueue API and structures can not be usd in Linux.
> >
> > Not sure what you are smoking, but "there's unsigned long in *bsd
> > version, lets r
On Fri, Nov 03, 2006 at 07:49:16PM +0100, Oleg Verych ([EMAIL PROTECTED]) wrote:
> [ Please do not answer just to answer, cc list is big, no one from ]
> [ The Big Jury seems to care. (well, Jonathan does, but he wasn't in cc) ]
>
> Friendly, Oleg.
Just in case some misunderstanding happend
On Fri, Nov 03, 2006 at 07:49:16PM +0100, Oleg Verych ([EMAIL PROTECTED]) wrote:
> > applications can be found on project's homepage.
> > There is a link to archive there, where you can find plenty of sources.
>
> But no single makefile. Or what CC and options do not mater really?
> You can easily
On Wed, Nov 01, 2006 at 09:57:46PM +0300, Evgeniy Polyakov wrote:
> On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED])
> wrote:
[]
> > Where's real-life application to do configure && make && make install?
>
> Your real life or mine as developer?
> I fortunately do not kno
On Fri, Nov 03, 2006 at 10:42:04AM +0800, zhou drangon ([EMAIL PROTECTED])
wrote:
> As for the VFS system, when we introduce the AIO machinism, we add aio_read,
> aio_write, etc... to file ops, and then we make the read, write op to
> call aio_read,
> aio_write, so that we only remain one implemen
On Fri, Nov 03, 2006 at 09:57:12AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> > So, kqueue API and structures can not be usd in Linux.
>
> Not sure what you are smoking, but "there's unsigned long in *bsd
> version, lets rewrite it from scratch" sounds like very bad idea. What
> about fixin
From: Pavel Machek <[EMAIL PROTECTED]>
Date: Fri, 3 Nov 2006 09:57:12 +0100
> Not sure what you are smoking, but "there's unsigned long in *bsd
> version, lets rewrite it from scratch" sounds like very bad idea. What
> about fixing that one bit you don't like?
I disagree, it's more like since we
Hi!
> > returns, which thread are you referring to? Nicholas Miell, in "The
> > Proposed Linux kevent API" thread, seems to think that there are no
> > advantages over kqueue to justify the incompatibility, an argument you
> > made no effort to refute. I've also read the Kevent wiki at
> > linux
On Thu, Nov 02, 2006 at 11:40:43AM -0800, Nate Diller ([EMAIL PROTECTED]) wrote:
> Are you saying that the *only* reason we choose not to be
> source-compatible with BSD is the 32 bit userland on 64 bit arch
> problem? I've followed every thread that gmail 'kqueue' search
I.e. do you want that ge
2006/11/2, Eric Dumazet <[EMAIL PROTECTED]>:
zhou drangon a écrit :
> performance is great, and we are exciting at the result.
>
> I want to know why there can be so much improvement, can we improve
> epoll too ?
Why did you remove most of CC addresses but lkml ?
Dont do that please...
I seldom
On 11/1/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 06:12:41PM -0800, Nate Diller ([EMAIL PROTECTED]) wrote:
> Indesiciveness has certainly been an issue here, but I remember akpm
> and Ulrich both giving concrete suggestions. I was particularly
> interested in Andrew
On Wed, Nov 01, 2006 at 06:12:41PM -0800, Nate Diller ([EMAIL PROTECTED]) wrote:
> Indesiciveness has certainly been an issue here, but I remember akpm
> and Ulrich both giving concrete suggestions. I was particularly
> interested in Andrew's request to explain and justify the differences
> betwee
On 11/1/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED]) wrote:
>
> Hallo, Evgeniy Polyakov.
Hello, Oleg.
> On 2006-11-01, you wrote:
> []
> >> Quantifying "how much more scalable" would be nice, as would be some
> >> exam
On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED]) wrote:
>
> Hallo, Evgeniy Polyakov.
Hello, Oleg.
> On 2006-11-01, you wrote:
> []
> >> Quantifying "how much more scalable" would be nice, as would be some
> >> example where it is useful. ("It makes my webserver twice as
Hallo, Evgeniy Polyakov.
On 2006-11-01, you wrote:
[]
>> Quantifying "how much more scalable" would be nice, as would be some
>> example where it is useful. ("It makes my webserver twice as fast on
>> monster 64-cpu box").
>
> Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with
On Wed, Nov 01, 2006 at 05:05:51PM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Hi!
Hi Pavel.
> > Kevent is a generic subsytem which allows to handle event notifications.
> > It supports both level and edge triggered events. It is similar to
> > poll/epoll in some cases, but it is more scala
Hi!
> > > Generic event handling mechanism.
> > >
> > > Consider for inclusion.
> > >
> > > Changes from 'take21' patchset:
> >
> > We are not interrested in how many times you spammed us, nor we want
> > to know what was wrong in previous versions. It would be nice to have
> > short summary of
On Wed, 1 Nov 2006, Pavel Machek wrote:
> Hi!
>
> > Generic event handling mechanism.
> >
> > Consider for inclusion.
> >
> > Changes from 'take21' patchset:
>
> We are not interrested in how many times you spammed us, nor we want
> to know what was wrong in previous versions. It would be nice
On Wed, Nov 01, 2006 at 02:06:14PM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Hi!
>
> > Generic event handling mechanism.
> >
> > Consider for inclusion.
> >
> > Changes from 'take21' patchset:
>
> We are not interrested in how many times you spammed us, nor we want
> to know what was wr
Hi!
> Generic event handling mechanism.
>
> Consider for inclusion.
>
> Changes from 'take21' patchset:
We are not interrested in how many times you spammed us, nor we want
to know what was wrong in previous versions. It would be nice to have
short summary of what this is good for, instead.
Generic event handling mechanism.
Consider for inclusion.
Changes from 'take21' patchset:
* minor cleanups (different return values, removed unneded variables,
whitespaces and so on)
* fixed bug in kevent removal in case when kevent being removed
is the same as overflow_kevent (spotted by
24 matches
Mail list logo
