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
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 can create
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
buffer
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 the
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 have
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_wait).
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
they
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: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 kernel)
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
userspace
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, when in
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])
wrote:
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 full ring
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
buffer (the
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 actually
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
remote
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 first
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:
Ok,
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.
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 be
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
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?
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 with your
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 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 which by
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 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 will
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 because of
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
userspace can
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 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
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-date
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
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
34 matches
Mail list logo
