linux-kernel - Re: [take12 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]

Date:	Tue, 22 Aug 2006 15:01:44 -0700
From:	Andrew Morton <akpm@...l.org>
To:	"Randy.Dunlap" <rdunlap@...otime.net>
Cc:	Nicholas Miell <nmiell@...cast.net>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [take12 0/3] kevent: Generic event handling mechanism.

On Tue, 22 Aug 2006 14:37:47 -0700
"Randy.Dunlap" <rdunlap@...otime.net> wrote:

> On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:
> 
> > On Wed, 2006-08-23 at 00:16 +0400, Evgeniy Polyakov wrote:
> > > On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell (nmiell@...cast.net) wrote:
> > > > On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
> > > > Of course, since you already know how all this stuff is supposed to
> > > > work, you could maybe write it down somewhere?
> > > 
> > > I will write documantation, but as you can see some interfaces are
> > > changed.
> > 
> > Thanks; rapidly changing interfaces need good documentation even more
> > than stable interfaces simply because reverse engineering the intended
> > API from a changing implementation becomes even more difficult.
> 
> OK, I don't quite get it.
> Can you be precise about what you would like?
> 
> a.  good documentation
> b.  a POSIX API
> c.  a Windows-compatible API
> d.  other?
> 
> and we won't make you use any of this code.
> 

Today seems to be beat-up-Nick day?

This is a major, major new addition to the kernel API.  It's a big deal. 
Getting it documented prior to committing ourselves is a useful part of the
review process.  It certainly can't hurt, and it might help.  It is a
little too soon to spend too much time on that though.  (It's actually
_better_ if someone other than the developer writes the documentation,
too).

And the "why not emulate kqueue" question strikes me as an excellent one. 
Presumably a lot of developer thought and in-field experience has gone into
kqueue.  It would benefit us to use that knowledge as much as we can.

I mean, if there's nothing wrong with kqueue then let's minimise app
developer pain and copy it exactly.  If there _is_ something wrong with
kqueue then let us identify those weaknesses and then diverge.  Doing
something which looks the same and works the same and does the same thing
but has a different API doesn't benefit anyone.
-
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/