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: <20060827.185744.82374086.davem@davemloft.net>
Date:	Sun, 27 Aug 2006 18:57:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	drepper@...hat.com
Cc:	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.

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