On Wed, Aug 23, 2006 at 09:09:20AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> > I can put nanoseconds as timer interval too (with aligned_u64 as David
> > mentioned), and put it for timeout value too - 64 bit nanosecods ends up
> > with 58 years, probably enough.
> > Structures with u64 a r
On Wed, 23 Aug 2006 11:50:56 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 12:07:58AM -0700, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > On Wed, 23 Aug 2006 10:56:59 +0400
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Aug 23, 2006 at 02:43:50A
On Wed, Aug 23, 2006 at 02:55:47PM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >We still do not know what uintptr_t is, and it looks like it is a pointer,
> >which is forbidden. Those numbers are not enough to make network AIO.
> >And
On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
We still do not know what uintptr_t is, and it looks like it is a pointer,
which is forbidden. Those numbers are not enough to make network AIO.
And actually is not compatible with kqueue already, so you will need to
write your own parser to
On Wed, Aug 23, 2006 at 12:34:25PM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> >No, it will change sizes of the structure in kernelspace and userspace,
> >so they just can not communicate.
>
> struct kevent {
> uintptr_t ident;
On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
No, it will change sizes of the structure in kernelspace and userspace,
so they just can not communicate.
struct kevent {
uintptr_t ident;/* identifier for this event */
short filter; /* filter for event */
u_short
On Wed, Aug 23, 2006 at 11:49:22AM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> >> Only void * I'm seeing belongs to the user, (udata) perhaps you are
> >> talking of something different?
> >
> >Yes, exactly about it.
> >
> >I put union {
> >u32 a[2];
> >void *b;
> >}
> >epcial
On Wed, Aug 23, 2006 at 11:58:20AM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> >
> > Let's then place there a structure with 64bit seconds and nanoseconds,
> > similar to timspec, but without longs there.
>
> You need 64bit (or at least more than
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> Let's then place there a structure with 64bit seconds and nanoseconds,
> similar to timspec, but without longs there.
You need 64bit (or at least more than 32bit) for the seconds,
otherwise you add a y2038 problem which would be sad in new code.
Re
On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Wed, Aug 23, 2006 at 10:22:06AM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >void * in structure exported to userspace is forbidden.
>
> Only void * I'm seeing belongs to the
On Wed, Aug 23, 2006 at 10:22:06AM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >void * in structure exported to userspace is forbidden.
>
> Only void * I'm seeing belongs to the user, (udata) perhaps you are
> talking of something dif
On 8/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
void * in structure exported to userspace is forbidden.
Only void * I'm seeing belongs to the user, (udata) perhaps you are
talking of something different?
long in syscall requires wrapper in per-arch code (although that
workaround _is_
On Wed, 2006-08-23 at 00:35 -0700, David Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, 23 Aug 2006 00:07:58 -0700
>
> > I wonder whether designing-in a millisecond granularity is the right thing
> > to do. If in a few years the kernel is running tickless with high-res clock
On Wed, 2006-08-23 at 10:22 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 06:36:07PM -0700, Nicholas Miell ([EMAIL PROTECTED])
> wrote:
> > int kevent_get_events(int ctl_fd, unsigned int min_nr,
> > unsigned int max_nr, unsigned int timeout,
> > void *buf, unsign
On Wed, Aug 23, 2006 at 12:07:58AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Wed, 23 Aug 2006 10:56:59 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Aug 23, 2006 at 02:43:50AM +0200, Jari Sundell ([EMAIL PROTECTED])
> > wrote:
> > > Actually, I didn't miss that, it
I wonder whether designing-in a millisecond granularity is the right thing
to do. If in a few years the kernel is running tickless with high-res clock
interrupt sources, that might look a bit lumpy.
I'd second that - when working on DCCP I've done a lot of the work in
microseconds and it made q
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 23 Aug 2006 00:07:58 -0700
> I wonder whether designing-in a millisecond granularity is the right thing
> to do. If in a few years the kernel is running tickless with high-res clock
> interrupt sources, that might look a bit lumpy.
>
> Switching
On Wed, Aug 23, 2006 at 12:07:58AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Wed, 23 Aug 2006 10:56:59 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Aug 23, 2006 at 02:43:50AM +0200, Jari Sundell ([EMAIL PROTECTED])
> > wrote:
> > > Actually, I didn't miss that, it
On Wed, 23 Aug 2006 10:56:59 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 02:43:50AM +0200, Jari Sundell ([EMAIL PROTECTED])
> wrote:
> > Actually, I didn't miss that, it is an orthogonal issue. A timespec
> > timeout parameter for the syscall does not imply the use
On Wed, Aug 23, 2006 at 02:43:50AM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> Actually, I didn't miss that, it is an orthogonal issue. A timespec
> timeout parameter for the syscall does not imply the use of timespec
> in any timer event, etc. Nor is there any timespec timer in kqueue's
> st
On Tue, Aug 22, 2006 at 04:46:19PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> DaveM says there are example programs for the current interfaces. I
> must admit I haven't seen those either. So if possible, point the world
> to them again. If you do that now I'll review everything and writ
On Tue, Aug 22, 2006 at 06:36:07PM -0700, Nicholas Miell ([EMAIL PROTECTED])
wrote:
> == The Proposed Linux kevent API ==
>
> The proposed Linux kevent API is a new unified event handling
> interface, similar in spirit to Windows completion ports and Solaris
> completion ports and similar in fac
Ulrich Drepper writes:
I so far also haven't taken the time to look exactly at the
interface. I plan to do it asap since this is IMO our big chance
to get it right. I want to have a unifying interface which can
handle all the different events we need and which come up today
and tomorrow. We hav
On Tue, 2006-08-22 at 16:46 -0700, Ulrich Drepper wrote:
> I so far also haven't taken the time to look exactly at the interface.
> I plan to do it asap since this is IMO our big chance to get it right.
> I want to have a unifying interface which can handle all the different
> events we need and wh
On Tue, 2006-08-22 at 16:06 -0700, David Miller wrote:
> With the time you spent writing this long email alone you could have
> worked on either documenting Evgeniy's interfaces or trying to write
> test applications against kevent to validate how useful the interfaces
> are and if there are any pr
On 8/23/06, David Miller <[EMAIL PROTECTED]> wrote:
> There are system calls that take timespec, so I assume the magic is
> already available for handling the timeout argument of kevent.
System calls are one thing, they can be translated for these
kinds of situations. But this doesn't help, and
From: "Jari Sundell" <[EMAIL PROTECTED]>
Date: Wed, 23 Aug 2006 02:28:32 +0200
> There are system calls that take timespec, so I assume the magic is
> already available for handling the timeout argument of kevent.
System calls are one thing, they can be translated for these
kinds of situations.
On 8/23/06, Alexey Kuznetsov <[EMAIL PROTECTED]> 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
I so far also haven't taken the time to look exactly at the interface.
I plan to do it asap since this is IMO our big chance to get it right.
I want to have a unifying interface which can handle all the different
events we need and which come up today and tomorrow. We have to be able
to handle not
On Tue, 22 Aug 2006 15:17:47 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 22 Aug 2006 15:01:44 -0700
>
> > If there _is_ something wrong with kqueue then let us identify those
> > weaknesses and then diverge.
>
> Evgeniy already enume
On Tue, 22 Aug 2006 15:58:12 -0700 Nicholas Miell wrote:
> On Tue, 2006-08-22 at 14:37 -0700, Randy.Dunlap 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, Nic
Hello!
> >No way - timespec uses long.
>
> I must have missed that discussion. Please enlighten me in what regard
> using an opaque type with lower resolution is preferable to a type
> defined in POSIX for this sort of purpose.
Let me explain, as a person who did this mistake and deeply
regrets
From: Nicholas Miell <[EMAIL PROTECTED]>
Date: Tue, 22 Aug 2006 15:58:12 -0700
> Honestly, somebody with enough clout to make it stick needs to write out
> a spec describing what new kernel interfaces should look like and how
> they should fit in with existing interfaces.
With the time you spent
On Tue, 2006-08-22 at 14:25 -0700, David Miller wrote:
> From: Nicholas Miell <[EMAIL PROTECTED]>
> Date: Tue, 22 Aug 2006 14:13:40 -0700
>
> > And how is the quality of the work to be judged if the work isn't
> > commented, documented and explained, especially the userland-visible
> > parts that
On Tue, 2006-08-22 at 14:37 -0700, Randy.Dunlap 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 ([EMAIL
> > > PROTECTED]) wrote:
> > > > On Tue, 2006-0
On 8/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
Word "polling" really confuses me here, but now I understand you.
Such approach actually has unresolved issues - consider for
example a situation when all provided events are ready immediately - what
should be returned (as far as I recall th
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 22 Aug 2006 15:01:44 -0700
> If there _is_ something wrong with kqueue then let us identify those
> weaknesses and then diverge.
Evgeniy already enumerated this, both on his web site and in the
current thread.
Unlike some people seem to imply, E
On Tue, 22 Aug 2006 14:37:47 -0700
"Randy.Dunlap" <[EMAIL PROTECTED]> 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 ([EMAIL
> > > PROTECTED]) 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 ([EMAIL
> > PROTECTED]) wrote:
> > > On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
> > > Of course, since
From: Nicholas Miell <[EMAIL PROTECTED]>
Date: Tue, 22 Aug 2006 14:13:40 -0700
> And how is the quality of the work to be judged if the work isn't
> commented, documented and explained, especially the userland-visible
> parts that *cannot* *ever* *be* *changed* *or* *removed* once they're in
> a s
On Wed, 2006-08-23 at 00:16 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell ([EMAIL PROTECTED])
> 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 co
On Tue, 2006-08-22 at 13:36 -0700, David Miller wrote:
> From: Nicholas Miell <[EMAIL PROTECTED]>
> Date: Tue, 22 Aug 2006 13:00:23 -0700
>
> > I'm not the one proposing the new (potentially wrong) interface. The
> > onus isn't on me.
>
> You can't demand a volunteer to do work, period.
>
> If i
From: Nicholas Miell <[EMAIL PROTECTED]>
Date: Tue, 22 Aug 2006 13:00:23 -0700
> I'm not the one proposing the new (potentially wrong) interface. The
> onus isn't on me.
You can't demand a volunteer to do work, period.
If it matters to you, you have the option of doing the work.
Otherwise you ca
On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell ([EMAIL PROTECTED])
wrote:
> On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
> > On Tue, Aug 22, 2006 at 02:29:48AM -0700, Nicholas Miell ([EMAIL
> > PROTECTED]) wrote:
> > > > > Is any of this documented anywhere? I'd think that
On Tue, 2006-08-22 at 10:59 -0400, James Morris wrote:
> On Tue, 22 Aug 2006, Nicholas Miell wrote:
>
> > In this brave new world of always stable kernel development, the time a
> > new interface has for public testing before a new kernel release is
> > drastically shorter than the old unstable de
On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 02:29:48AM -0700, Nicholas Miell ([EMAIL PROTECTED])
> wrote:
> > > > Is any of this documented anywhere? I'd think that any new userspace
> > > > interfaces should have man pages explaining their use and some exa
On Tue, Aug 22, 2006 at 09:14:30PM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> Changing kevents are done with a separate system call from polling
> afaics, thus every change requires a context switch. This in contrast
> to BSD's kqueue which allows user-space to pass the changes when
> kevent
On 8/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Not to mention the name used causes (at least me) some confusion with BSD's
> kqueue implementation. Skimming over the patches it actually looks somewhat
> like kqueue with the more interesting features removed, like the ability to
> pass
On Tue, Aug 22, 2006 at 06:57:05PM +0200, Jari Sundell ([EMAIL PROTECTED])
wrote:
> On 8/22/06, Nicholas Miell <[EMAIL PROTECTED]> wrote:
> >
> >
> >OK, so with literally a dozen different interfaces to queue events to
> >userspace, all of which are apparently inadequate and in need of
> >replacem
Not to mention the name used causes (at least me) some confusion with
BSD's kqueue implementation. Skimming over the patches it actually
looks somewhat like kqueue with the more interesting features removed,
like the ability to pass the filter changes simultaneously with
polling.
Maybe this is a
On Tue, 22 Aug 2006, Nicholas Miell wrote:
> In this brave new world of always stable kernel development, the time a
> new interface has for public testing before a new kernel release is
> drastically shorter than the old unstable development series, and if
> nobody is documenting how this stuff i
On Tue, Aug 22, 2006 at 02:29:48AM -0700, Nicholas Miell ([EMAIL PROTECTED])
wrote:
> > > Is any of this documented anywhere? I'd think that any new userspace
> > > interfaces should have man pages explaining their use and some example
> > > code before getting merged into the kernel to shake out
On Tue, 2006-08-22 at 12:37 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 01:17:52AM -0700, Nicholas Miell ([EMAIL PROTECTED])
> wrote:
> > On Tue, 2006-08-22 at 11:24 +0400, Evgeniy Polyakov wrote:
> > > On Tue, Aug 22, 2006 at 12:00:51AM -0700, Nicholas Miell ([EMAIL
> > > PROTECTED]
On Tue, 2006-08-22 at 01:23 -0700, David Miller wrote:
> From: Nicholas Miell <[EMAIL PROTECTED]>
> Date: Tue, 22 Aug 2006 01:17:52 -0700
>
> > Is any of this documented anywhere? I'd think that any new userspace
> > interfaces should have man pages explaining their use and some example
> > code b
On Tue, Aug 22, 2006 at 01:17:52AM -0700, Nicholas Miell ([EMAIL PROTECTED])
wrote:
> On Tue, 2006-08-22 at 11:24 +0400, Evgeniy Polyakov wrote:
> > On Tue, Aug 22, 2006 at 12:00:51AM -0700, Nicholas Miell ([EMAIL
> > PROTECTED]) wrote:
> > > On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wr
From: Nicholas Miell <[EMAIL PROTECTED]>
Date: Tue, 22 Aug 2006 01:17:52 -0700
> Is any of this documented anywhere? I'd think that any new userspace
> interfaces should have man pages explaining their use and some example
> code before getting merged into the kernel to shake out any interface
> p
On Tue, 2006-08-22 at 11:24 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 12:00:51AM -0700, Nicholas Miell ([EMAIL PROTECTED])
> wrote:
> > On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wrote:
> > > Generic event handling mechanism.
> >
> > Since this is the sixth[1] event notifi
On Tue, Aug 22, 2006 at 12:00:51AM -0700, Nicholas Miell ([EMAIL PROTECTED])
wrote:
> On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wrote:
> > Generic event handling mechanism.
>
> Since this is the sixth[1] event notification system that's getting
> added to the kernel, could somebody plea
On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wrote:
> Generic event handling mechanism.
Since this is the sixth[1] event notification system that's getting
added to the kernel, could somebody please convince me that the
userspace API is right this time? (Evidently, the others weren't and ar
Generic event handling mechanism.
Changes from 'take11' patchset:
* include missing headers into patchset
* some trivial code cleanups (use goto instead if if/else games and so on)
* some whitespace cleanups
* check for ready_callback() callback before main loop which should save us
some tic
60 matches
Mail list logo
