[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061017163536.GA17692@2ka.mipt.ru>
Date: Tue, 17 Oct 2006 20:35:36 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Eric Dumazet <dada1@...mosbay.com>
Cc: Johann Borck <johann.borck@...sedata.com>,
Ulrich Drepper <drepper@...hat.com>,
Ulrich Drepper <drepper@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 1/4] kevent: Core files.
On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet (dada1@...mosbay.com) 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 mental reading abilities.
> > Ulrich, does above approach sound good for you?
> > I actually do not want to reimplement something, that will be
> > pointed to with words 'no matter what you say, it is broken and I do not
> > want it' again :).
>
> In my humble opinion, you should first write a 'real application', to show how
> the mmap buffer and kevent syscalls would be used (fast path and
> slow/recovery paths). I am sure it would be easier for everybody to agree on
> the API *before* you start coding a *lot* of hard (kernel) stuff : It would
> certainly save your mental CPU cycles (and ours too :) )
>
> This 'real application' could be the event loop of a simple HTTP server, or a
> basic 'echo all' server. Adding the bits about timers events and signals
> should be done too.
I wrote one with previous ring buffer implementation - it used timers
and echoed when they fired, it was even described in details in one of the
lwn.net articles.
I'm not going to waste others and my time implementing feature requests
without at least _some_ feedback from those who asked them.
In case when person, originally requested some feature, does not answer
and there are other opinions, only they will be get into account of
course.
> Eric
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists