linux-kernel - Re: [take14 0/3] kevent: Generic event handling mechanism.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1156732833.2358.13.camel@entropy>
Date:	Sun, 27 Aug 2006 19:40:33 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	David Miller <davem@...emloft.net>
Cc:	drepper@...hat.com, johnpol@....mipt.ru,
	linux-kernel@...r.kernel.org, akpm@...l.org,
	netdev@...r.kernel.org, zach.brown@...cle.com, hch@...radead.org,
	chase.venters@...entec.com
Subject: Re: [take14 0/3] kevent: Generic event handling mechanism.

On Sun, 2006-08-27 at 18:57 -0700, David Miller wrote:
> From: Ulrich Drepper <drepper@...hat.com>
> Date: Sun, 27 Aug 2006 14:03:33 -0700
> 
> > The biggest problem I see so far is the integration into the existing
> > interfaces.  kevent notification *really* should be usable as a new
> > sigevent type.  Whether the POSIX interfaces are liked by kernel folks
> > or not, they are what the majority of the userlevel programmers use.
> > The mechanism is easily extensible.  I've described this in my paper.  I
> > cannot comment on the complexity of the kernel side but I'd imagine it's
> > not much more difficult, just different from what is implemented now.
> > Let's learn for a change from the mistakes of the past.  The new and
> > innovative AIO interfaces never took off because their implementation
> > differs so much from the POSIX interfaces.  People are interested in
> > portable code.  So, please, let's introduce SIGEV_KEVENT.  Then we
> > magically get timer notification etc for free.
> 
> I have to disagree with this.
> 
> SigEvent, and signals in general, are crap.  They are complex
> and userland gets it wrong more often than not.  Interfaces
> for userland should be simple, signals are not simple.  A core
> loop that says "give me events to process", on the other hand,
> is.  And this is what is most natural for userspace.
> 
> The user can say when he wants the process events.  In fact,
> ripping out the complex signal handling will be a welcome
> change for most server applications.
> 
> We are going to require the use of a new interface to register
> the events anyways, why keep holding onto the delivery baggage
> as well when we can break free of those limitations?

struct sigevent is the POSIX method for describing how event
notifications are delivered.

Two methods are specified in POSIX -- SIGEV_SIGNAL, which delivers a
signal to the process and SIGEV_THREAD which creates a new thread in the
process and calls a user-supplied function. In addition to these two
methods, Linux also implements SIGEV_THREAD_ID, which sends a signal to
a specific thread (this is used internally by glibc to implement
SIGEV_THREAD, but I imagine that would change on the addition of
SIGEV_KEVENT).

Ulrich is suggesting the addition of SIGEV_KEVENT, which causes the
event notification to be delivered to a specific kevent queue. This
would allow for event delivery to kevent queues from POSIX AIO
completions, POSIX message queues, POSIX timers, glibc's async name
resolution interface and anything else that might use a struct sigevent
in the future.

-- 
Nicholas Miell <nmiell@...cast.net>

-
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/