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: <44F250D9.90904@redhat.com>
Date:	Sun, 27 Aug 2006 19:11:37 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	David Miller <davem@...emloft.net>
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.

David Miller wrote:
> 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.

You miss the point.

sigevent has nothing necessarily to do with signals.  I don't want
signals.  I just want the same interface to specify the action to be used.

If I'm using

  struct sigevent sigev;
  int kfd;

  kfd = kevent_create (...);

  sigev.sigev_notify = SIGEV_KEVENT;
  sigev.sigev_kfd = kfd;
  sigev.sigev_valie.sival_ptr = &some_data;

then I can use this sigev variable in an unmodified timer_create call.
The kernel would see SIGEV_KEVENT (as opposed to SIGEV_SIGNAL etc) and
**not** generate a signal but instead create the event in the kevent queue.

The proposal to use sigevent has nothing to do with signals.  It's just
about the interface and to have smooth integration with existing
functionality.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)