From: Jeff Garzik <jeff@garzik.org>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: David Miller <davem@davemloft.net>,
Ulrich Drepper <drepper@redhat.com>,
Andrew Morton <akpm@osdl.org>, netdev <netdev@vger.kernel.org>,
Zach Brown <zach.brown@oracle.com>,
Christoph Hellwig <hch@infradead.org>,
Chase Venters <chase.venters@clientec.com>,
Johann Borck <johann.borck@densedata.com>,
linux-kernel@vger.kernel.org, Jamal Hadi Salim <hadi@cyberus.ca>,
Ingo Molnar <mingo@elte.hu>,
linux-fsdevel@vger.kernel.org
Subject: Re: [take32 0/10] kevent: Generic event handling mechanism.
Date: Wed, 10 Jan 2007 06:11:26 -0500 [thread overview]
Message-ID: <45A4C9DE.8020605@garzik.org> (raw)
In-Reply-To: <11684170003907@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> Generic event handling mechanism.
>
> 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 scalable, it is faster and
> allows to work with essentially eny kind of events.
>
> Events are provided into kernel through control syscall and can be read
> back through ring buffer or using usual syscalls.
> Kevent update (i.e. readiness switching) happens directly from internals
> of the appropriate state machine of the underlying subsytem (like
> network, filesystem, timer or any other).
>
> Homepage:
> http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
>
> Documentation page:
> http://linux-net.osdl.org/index.php/Kevent
>
> Consider for inclusion.
>
> With this release I start 3 days resending timeout - i.e. each third day
> I will send either new version (if something new was requested and agreed
> to be implemented) or resending with back counter started from three. When
> back counter hits zero after three resendings I consider there is no interest
> in subsystem and I will stop further sending.
>
> I really doubt it is a good way to tell the world about my work, and I bet you
> all tired from those pathos words, but I really would like to get some feedback,
> since I want to start to work on network AIO, but sending mails into
> unfeedbackable 'destination' really does not motivate me for that.
>
> Thanks for understanding and your time.
Once the rate of change slows, Andrew should IMO definitely pick this up.
If you wanted to make this process automatic, create a git branch that
Andrew and others can pull.
I like the direction so far, and think it should be in -mm for wider
testing and review.
Jeff
next prev parent reply other threads:[~2007-01-10 11:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <315adqaa0591036@2ka.mipt.ru>
2007-01-10 8:16 ` [take32 0/10] kevent: Generic event handling mechanism Evgeniy Polyakov
2007-01-10 8:16 ` [take32 1/10] kevent: Description Evgeniy Polyakov
2007-01-10 8:16 ` [take32 2/10] kevent: Core files Evgeniy Polyakov
2007-01-10 8:16 ` [take32 3/10] kevent: poll/select() notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 4/10] kevent: Socket notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 5/10] kevent: Timer notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 6/10] kevent: Pipe notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 7/10] kevent: Signal notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 8/10] kevent: Kevent posix timer notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 9/10] kevent: Private userspace notifications Evgeniy Polyakov
2007-01-10 8:16 ` [take32 10/10] kevent: Kevent based AIO (aio_sendfile()) Evgeniy Polyakov
2007-01-10 11:11 ` Jeff Garzik [this message]
2007-01-10 11:30 ` [take32 0/10] kevent: Generic event handling mechanism Evgeniy Polyakov
2007-01-10 11:56 ` Jeff Garzik
2007-01-10 12:14 ` Evgeniy Polyakov
2007-01-10 12:18 ` Kevent bonus: epoll implementaion over kevent Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45A4C9DE.8020605@garzik.org \
--to=jeff@garzik.org \
--cc=akpm@osdl.org \
--cc=chase.venters@clientec.com \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=hadi@cyberus.ca \
--cc=hch@infradead.org \
--cc=johann.borck@densedata.com \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=zach.brown@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.