Evgeniy Polyakov a e'crit :
On Tue, Oct 17, 2006 at 06:45:54PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
I am not sure I understand what you wrote, English is not our native language.
I think many people gave you feedbacks. I feel that all feedback on this
mailing list is constructive. M
On Tue, Oct 17, 2006 at 06:45:54PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 18:35, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> wrote:
> > > On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> >
On Tuesday 17 October 2006 18:35, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> > > Ok, there is one apologist for mmap buffer implementation, who forced
> > > me to create
On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
>
> > Ok, there is one apologist for mmap buffer implementation, who forced me
> > to create first implementation, which was dropped due to absense of
> >
On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> Ok, there is one apologist for mmap buffer implementation, who forced me
> to create first implementation, which was dropped due to absense of
> remote mental reading abilities.
> Ulrich, does above approach sound good for you?
> I actual
On Tue, Oct 17, 2006 at 05:32:28PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > So the most complex case is when user is going to use both interfaces,
> > and it's steps when mapped ring buffer has overflow.
> > In that case user can either read and mark some events as ready in ring
> > buff
On Tuesday 17 October 2006 17:09, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 04:25:00PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet
> > > ([EMAIL PROTECTED])
> >
> >
On Tuesday 17 October 2006 16:25, Eric Dumazet wrote:
> On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet
([EMAIL PROTECTED])
> wrote:
> > > > What about the case, which I described in other e-mail, when in case
of
> > > > the fu
On Tue, Oct 17, 2006 at 04:25:00PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> wrote:
> > > > What about the case, which I described in other e-mail, whe
On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > What about the case, which I described in other e-mail, when in case of
> > > the full ring buffer, no new events are written there, and when
> > > us
On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > What about the case, which I described in other e-mail, when in case of
> > the full ring buffer, no new events are written there, and when
> > userspace commits (i.e. marks as ready to be freed or requeued by ke
On Tuesday 17 October 2006 15:42, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 03:19:36PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
> > > I can add such notification, but its existense _is_ the broken design.
> > > After such
On Tue, Oct 17, 2006 at 03:19:36PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
>
> > I can add such notification, but its existense _is_ the broken design.
> > After such condition happend, all new events will dissapear (although
> >
On Tue, Oct 17, 2006 at 08:12:04AM -0500, Chase Venters ([EMAIL PROTECTED])
wrote:
> > > > Regarding mukevent I'm thinking of a event-type specific struct, that
> > > > is filled by the originating code, and placed into a per-event-type
> > > > ring buffer (which requires modification of kevent_w
On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
> I can add such notification, but its existense _is_ the broken design.
> After such condition happend, all new events will dissapear (although
> they are still accessible through usual queue) from mapped buffer.
>
> While writing this I h
On Tuesday 17 October 2006 05:42, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters
([EMAIL PROTECTED]) wrote:
> > On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> > > Regarding mukevent I'm thinking of a event-type specific struct, that
> > > is filled by th
On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> > Regarding mukevent I'm thinking of a event-type specific struct, that is
> > filled by the originating code, and placed into a per-event-type ring
> > buff
On Tue, Oct 17, 2006 at 07:10:14AM +0200, Johann Borck ([EMAIL PROTECTED])
wrote:
> Ulrich Drepper wrote:
> > Evgeniy Polyakov wrote:
> >> Existing design does not allow overflow.
> >
> > And I've pointed out a number of times that this is not practical at
> > best. There are event sources which
On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> Regarding mukevent I'm thinking of a event-type specific struct, that is
> filled by the originating code, and placed into a per-event-type ring
> buffer (which requires modification of kevent_wait).
I'd personally worry about an implementat
Ulrich Drepper wrote:
> Evgeniy Polyakov wrote:
>> Existing design does not allow overflow.
>
> And I've pointed out a number of times that this is not practical at
> best. There are event sources which can create events which cannot be
> coalesced into one single event as it would be required wit
On Mon, Oct 16, 2006 at 03:16:15AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >The whole idea of mmap buffer seems to be broken, since those who asked
> >for creation do not like existing design and do not show theirs...
>
> What kind of argumentation is that?
>
Evgeniy Polyakov wrote:
The whole idea of mmap buffer seems to be broken, since those who asked
for creation do not like existing design and do not show theirs...
What kind of argumentation is that?
"Because my attempt to implement it doesn't work and nobody right
away has a better sugg
On Sun, Oct 15, 2006 at 04:22:45PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >Existing design does not allow overflow.
>
> And I've pointed out a number of times that this is not practical at
> best. There are event sources which can create events which cannot
Evgeniy Polyakov wrote:
Existing design does not allow overflow.
And I've pointed out a number of times that this is not practical at
best. There are event sources which can create events which cannot be
coalesced into one single event as it would be required with your design.
Signals are
On Thursday 05 October 2006 16:15, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 04:01:19PM +0200, Hans Henrik Happe
([EMAIL PROTECTED]) wrote:
> > > And what happens when there are 3 empty at the beginning and \we need to
> > > put there 4 ready events?
> >
> > Couldn't there be 3 areas in t
On Thu, Oct 05, 2006 at 04:01:19PM +0200, Hans Henrik Happe ([EMAIL PROTECTED])
wrote:
> > And what happens when there are 3 empty at the beginning and \we need to
> > put there 4 ready events?
>
> Couldn't there be 3 areas in the mmap buffer:
>
> - Unused: entries that the kernel can alloc from
On Thursday 05 October 2006 12:21, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
> >
> > > Well, it is possible to create /sys/proc entry for that, and even now
> > > users
On Thu, Oct 05, 2006 at 02:09:31PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Thursday 05 October 2006 12:55, Evgeniy Polyakov wrote:
> > On Thu, Oct 05, 2006 at 12:45:03PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> > >
> > > What is missing or not obvious is : If events are skipped becau
On Thursday 05 October 2006 12:55, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 12:45:03PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> >
> > What is missing or not obvious is : If events are skipped because of
> > overflows, What happens ? Connections stuck forever ? Hope that
> > everything wi
On Thu, Oct 05, 2006 at 12:45:03PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Thursday 05 October 2006 12:21, Evgeniy Polyakov wrote:
> > On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet ([EMAIL PROTECTED])
> > > I may be wrong, but what is currently missing for me is :
> > >
> > >
On Thursday 05 October 2006 12:21, Evgeniy Polyakov wrote:
> On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet ([EMAIL PROTECTED])
> > I may be wrong, but what is currently missing for me is :
> >
> > - No hardcoded limit on the max number of events. (A process that can
> > open XXX.XXX files
On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
>
> > Well, it is possible to create /sys/proc entry for that, and even now
> > userspace can grow mapping ring until it is forbiden by kernel, which
> >
On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
> Well, it is possible to create /sys/proc entry for that, and even now
> userspace can grow mapping ring until it is forbiden by kernel, which
> means limit is reached.
No need for yet another /sys/proc entry.
Right now, I (for example)
On Wed, Oct 04, 2006 at 10:57:32AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> On 10/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
> >http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c
>
> These are simple programs
On 10/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c
These are simple programs which by themselves have problems. For
instance, I consider a very bad idea to hardcode the s
On Tue, Oct 03, 2006 at 11:34:02PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> On 9/20/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >This patch includes core kevent files:
> >[...]
>
> I tried to look at the example programs before and failed. I tried
> again. Where can I find up-to
On 9/20/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
This patch includes core kevent files:
[...]
I tried to look at the example programs before and failed. I tried
again. Where can I find up-to-date example code?
Some other points:
- I really would prefer not to rush all this into the u
Core files.
This patch includes core kevent files:
- userspace controlling
- kernelspace interfaces
- initialization
- notification state machines
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index dd63d
38 matches
Mail list logo
