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 ❖
Attachment:
signature.asc
Description: OpenPGP digital signature
- References:
- [take14 0/3] kevent: Generic event handling mechanism.
- From: Evgeniy Polyakov <[email protected]>
- Re: [take14 0/3] kevent: Generic event handling mechanism.
- From: Ulrich Drepper <[email protected]>
- Re: [take14 0/3] kevent: Generic event handling mechanism.
- From: David Miller <[email protected]>
- [take14 0/3] kevent: Generic event handling mechanism.
- Prev by Date: Re: [RFC] VFS: FS CoW using redirection
- Next by Date: Re: [PATCH 2/7] rename the provided execve functions to kernel_execve
- Previous by thread: Re: [take14 0/3] kevent: Generic event handling mechanism.
- Next by thread: Re: [take14 0/3] kevent: Generic event handling mechanism.
- Index(es):
 |