Re: [take22 0/4] kevent: Generic event handling mechanism.

[Pavel Machek <pavel@ucw.cz>]

Hi!

On Fri 2006-11-03 10:30:12, Jonathan Lemon wrote:
> In article <local.mail.linux-kernel/20061103084240.GB1184@2ka.mipt.ru>,
> Evgeniy Polyakov  <johnpol@2ka.mipt.ru> wrote:
> >On Thu, Nov 02, 2006 at 11:40:43AM -0800, Nate Diller
> >kqueue just can not be used as is in Linux (_maybe_ *bsd has different
> >types, not those which I found in /usr/include in my FC5 and Debian
> >distro). It will not work on x86_64 for example. Some kind of a pointer
> >or unsigned long in structures which are transferred between kernelspace
> >and userspace is so much questionable, than it is much better even do
> >not see there... (if I would not have so political correctness, I would
> >describe it in a much different words actually).
> >So, kqueue API and structures can not be usd in Linux.
> 
> Let me be a little blunt here: that is just so much bullshit.
> 
> Yes, I understand the problem that 32-bit userspace on a 64-bit kernel has.
> Mea culpa - I didn't forsee this years ago, and none of my many reviewers
> caught it either.  It was designed for 32/32 and 64/64, not 32/64.
> 
> However, this is trivially fixed by adding a union to the structure, as
> pointed out earlier on this list.  Code would still be source compatible
> with any kqueue apps, which is what counts.  Even NetBSD and FreeBSD have
> differing definitions of the kq constants, and nobody notices.

It has been show in this thread that kevent is too different to kqueue
as is... but what are the advantages of kevent? Perhaps we should use
kqueue on Linux, too (even if it means one more rewrite for you...?)

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html