On Wed, 24 Jun 2009 16:52:06 -0700 (PDT)
Davide Libenzi wrote:
> > umm, yes please, I believe the patches should be split. And I'm still
> > not seeing the justification for forcing CONFIG_EVENTFD onto all
> > CONFIG_AIO users!
>
> Eventfd notifications became part of the AIO API (it's not even
On Wed, 24 Jun 2009, Andrew Morton wrote:
> Split what? My skull?
Heh :)
> umm, yes please, I believe the patches should be split. And I'm still
> not seeing the justification for forcing CONFIG_EVENTFD onto all
> CONFIG_AIO users!
Eventfd notifications became part of the AIO API (it's not e
On Wed, 24 Jun 2009 15:47:47 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > Maybe there is such a reason, and it hasn't yet been beaten into my
> > skull. But I still think it should be done in a separate patch. One
> > which comes with a full description o
On Tue, 23 Jun 2009, Andrew Morton wrote:
> Maybe there is such a reason, and it hasn't yet been beaten into my
> skull. But I still think it should be done in a separate patch. One
> which comes with a full description of the reasons for the change, btw.
Since your skull seems pretty hard to b
On Tue, 23 Jun 2009 15:49:53 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > On Tue, 23 Jun 2009, Andrew Morton wrote:
> > >
> > > > That isn't for us to decide. Entire syscalls ca
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
> Davide Libenzi wrote:
>
> > On Tue, 23 Jun 2009, Andrew Morton wrote:
> >
> > > That isn't for us to decide. Entire syscalls can be disabled in config.
> >
> > That is not a well defined separate syscall tho
On Tue, 23 Jun 2009 14:48:51 -0700 (PDT)
Davide Libenzi wrote:
> > > This becomes pretty painful when the function calls other functions, for
> > > which just relays the error code.
> > > Should we be just documenting the error codes introduced by the function
> > > code, and say that the funct
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 14:34:50 -0700 (PDT)
> Davide Libenzi wrote:
>
> > On Tue, 23 Jun 2009, Andrew Morton wrote:
> >
> > > > Should functions be describing all the returned error codes, ala man
> > > > pages?
> > > >
> > >
> > > I think so.
> >
>
On Tue, 23 Jun 2009 14:34:50 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > > Should functions be describing all the returned error codes, ala man
> > > pages?
> > >
> >
> > I think so.
>
> This becomes pretty painful when the function calls other functio
On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > That isn't for us to decide. Entire syscalls can be disabled in config.
>
> That is not a well defined separate syscall though. It's a member/feature
> of the aiocb.
I don't know w
On Tue, 23 Jun 2009, Andrew Morton wrote:
> > Should functions be describing all the returned error codes, ala man pages?
> >
>
> I think so.
This becomes pretty painful when the function calls other functions, for
which just relays the error code.
Should we be just documenting the error codes
On Tue, 23 Jun 2009, Andrew Morton wrote:
> > > > +struct eventfd_ctx *eventfd_ctx_get(struct eventfd_ctx *ctx)
> > > > +{
> > > > + kref_get(&ctx->kref);
> > > > + return ctx;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(eventfd_ctx_get);
> > >
> > > doesn't match the code.
>
> You appear
On Tue, 23 Jun 2009, Andrew Morton wrote:
> That isn't for us to decide. Entire syscalls can be disabled in config.
That is not a well defined separate syscall though. It's a member/feature
of the aiocb.
- Davide
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
On Tue, 23 Jun 2009 14:03:22 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > The following patch changes the eventfd interface to de-couple the
> > > eventfd
> > > memory context,
On Tue, 23 Jun 2009 13:59:07 -0700 (PDT)
Davide Libenzi wrote:
> On Tue, 23 Jun 2009, Andrew Morton wrote:
>
> > On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> > Davide Libenzi wrote:
> >
> > > Another cleanup this patch does, is making AIO select EVENTFD, instead of
> > > adding a bunch of empty
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to rac
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > Another cleanup this patch does, is making AIO select EVENTFD, instead of
> > adding a bunch of empty function stubs inside eventfd.h in order to
> > handle the (AIO && !EVENTFD)
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> Another cleanup this patch does, is making AIO select EVENTFD, instead of
> adding a bunch of empty function stubs inside eventfd.h in order to
> handle the (AIO && !EVENTFD) case.
Given that we're trying to squeak this patch int
On Tue, 23 Jun 2009, Andrew Morton wrote:
> On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
> Davide Libenzi wrote:
>
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to rac
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last
On Tue, 23 Jun 2009, Gregory Haskins wrote:
> I think the lack of a way to got from a file* to a ctx* (or back) might
> be a problem. I am not an expert, but if I understood the gist of what
> Al Viro (cc'd) was saying early on, an fd can change meaning out from
> under you without warning.
>
>
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last instance of the file* goes away.
> Also, n
On Tue, 23 Jun 2009, Randy Dunlap wrote:
> kernel-doc syntax requires the function name + short description on one line,
> followed by parameters. Any longer function description then comes after
> the parameters.
>
> See Documentation/kernel-doc-nano-HOWTO.txt for more info,
> or ask me.
Will
On Tue, 23 Jun 2009, Avi Kivity wrote:
> On 06/23/2009 07:47 PM, Davide Libenzi wrote:
> > The following patch changes the eventfd interface to de-couple the eventfd
> > memory context, from the file pointer instance.
> > Without such change, there is no clean way to racely free handle the
> > POL
On 06/23/2009 07:47 PM, Davide Libenzi wrote:
The following patch changes the eventfd interface to de-couple the eventfd
memory context, from the file pointer instance.
Without such change, there is no clean way to racely free handle the
POLLHUP event sent when the last instance of the file* goes
Davide Libenzi wrote:
> The following patch changes the eventfd interface to de-couple the eventfd
> memory context, from the file pointer instance.
> Without such change, there is no clean way to racely free handle the
> POLLHUP event sent when the last instance of the file* goes away.
> Also, n
27 matches
Mail list logo
