linux-kernel - Re: [take22 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061105204741.GA1847@elf.ucw.cz>
Date:	Sun, 5 Nov 2006 21:47:41 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jonathan Lemon <jlemon@...gsvamp.com>
Cc:	linux-kernel@...r.kernel.org, johnpol@....mipt.ru
Subject: Re: [take22 0/4] kevent: Generic event handling mechanism.

Hi!

On Fri 2006-11-03 10:30:12, Jonathan Lemon wrote:
> In article <local.mail.linux-kernel/20061103084240.GB1184@....mipt.ru>,
> Evgeniy Polyakov  <johnpol@....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
-
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/