linux-kernel - Re: [take19 0/4] 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: <20061005090214.GB1015@2ka.mipt.ru>
Date:	Thu, 5 Oct 2006 13:02:15 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 0/4] kevent: Generic event handling mechanism.

On Wed, Oct 04, 2006 at 10:20:44AM -0700, Ulrich Drepper (drepper@...hat.com) wrote:
> Evgeniy Polyakov wrote:
> > It is completely possible to do what you describe without special
> > syscall parameters.
> 
> First of all, I don't see how this is efficiently possible.  The mask
> might change from call to call.

And you can add/remove signal events using existing kevent api between
calls.

> Second, hasn't it sunk in that inventing new ways to pass parameters is
> bad?  Programmers don't want to learn new ways for every new interface.
>  Reuse is good!

And creating special cases for usual events is bad.
There is unified way to deal with events in kevent -
add/remove/modify/wait on them, signals are just usual events.

> This applies to the signal mask here.
> 
> But there is another parameter falling into that category and I meant to
> mention it before: the timeout value.  All other calls except poll and
> especially all modern interfaces use a timespec pointer.  This is the
> way times are kept in userland code.  Don't try to force people to do
> something else.
> 
> Using a timespec also has the advantage that we can add an absolute
> timeout value mode (optional) instead of the relative timeout value.
> 
> In this context, we should/must be able to specify which clock the
> timeout is for (not as part of the wait call, but another control
> operation perhaps).  It's important to distinguish between
> CLOCK_REALTIME and CLOCK_MONOTONE.  Both have their use.

I think you wanted to say, that 'all event mechanism except the most
commonly used poll/select/epoll use timespec'.
I designed it to be similar to poll(), it is really good interface.
Nature of the waiting is to wait for some time, so I put there that
'some time'.

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



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