[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3f268590608221728r6cffd03i2f2dd12421b9f37@mail.gmail.com>
Date: Wed, 23 Aug 2006 02:28:32 +0200
From: "Jari Sundell" <sundell.software@...il.com>
To: "Alexey Kuznetsov" <kuznet@....inr.ac.ru>
Cc: "Evgeniy Polyakov" <johnpol@....mipt.ru>,
"Nicholas Miell" <nmiell@...cast.net>,
lkml <linux-kernel@...r.kernel.org>,
"David Miller" <davem@...emloft.net>,
"Ulrich Drepper" <drepper@...hat.com>,
"Andrew Morton" <akpm@...l.org>, 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 8/23/06, Alexey Kuznetsov <kuznet@....inr.ac.ru> wrote:
> Let me explain, as a person who did this mistake and deeply
> regrets about this.
>
> F.e. in this case you just cannot use kevents in 32bit application
> on x86_64, unless you add the whole translation layer inside kevent core.
> Even when you deal with plain syscall, translation is a big pain,
> but when you use mmapped buffer, it can be simply impossible.
>
> F.e. my mistake was "unsigned long" in struct tpacket_hdr in linux/if_packet.h.
> It makes use of mmapped packet socket essentially impossible by 32bit
> applications on 64bit archs.
There are system calls that take timespec, so I assume the magic is
already available for handling the timeout argument of kevent.
Although I'm not entirely sure about the kqueue timer interface, there
isn't any reason timespec would need to be written to the mmaped
buffer for the rest.
AFAICS, only struct ukevent is visible to the user, same would go for
kqueue's struct kevent.
Rakshasa
-
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/
Powered by blists - more mailing lists