Re: [patch] eventfd - revised interface and cleanups (2nd rev)
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 beat, would you like me to split it for ya? :) - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Wed, 24 Jun 2009 15:47:47 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 of the reasons for the change, btw. Since your skull seems pretty hard to beat, would you like me to split it for ya? :) Split what? My skull? 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! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
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 even delivered through a new syscall, from the AIO side - same existing aiocb struct and io_submit syscall) once we merged it, so IMHO (AIO !EVENTFD) would be similar to split AIO in AIO_READ and AIO_WRITE and have (AIO !AIO_WRITE). Considering that the kernel config, once you unleash the CONFIG_EMBEDDED pandora box, allows you to select (AIO !EVENTFD) w/out even a warning about possible userspace breakages, this makes it rather a confusing configuration if you ask me. It's not a biggie from the kernel side, just a few ugly errors wrappers around functions. For me AIO (or whatever userspace visible kernel subsystem) should select all the components that are part of the userspace API, but my argument ends here. - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Wed, 24 Jun 2009 16:52:06 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 delivered through a new syscall, from the AIO side - same existing aiocb struct and io_submit syscall) once we merged it, That was a regression for existing embedded AIO users ;) so IMHO (AIO !EVENTFD) would be similar to split AIO in AIO_READ and AIO_WRITE and have (AIO !AIO_WRITE). Considering that the kernel config, once you unleash the CONFIG_EMBEDDED pandora box, allows you to select (AIO !EVENTFD) w/out even a warning about possible userspace breakages, this makes it rather a confusing configuration if you ask me. Sure. But we do assume that one someone sets CONFIG_EMBEDDED, they know what they're doing. We prefer to give them maximum flexibility and foot-shooting ability. As long as the maintenance cost of doing so in each case is reasonable, of course. It's not a biggie from the kernel side, just a few ugly errors wrappers around functions. For me AIO (or whatever userspace visible kernel subsystem) should select all the components that are part of the userspace API, but my argument ends here. Sure, it's not a biggie either way. Doubtful if many tiny systems are using AIO anyway. Heck, lots of them are running 2.4.18... But from the general this-is-the-way-we-do-things POV, it's preferred that the two features be separable under CONFIG_EMBEDDED if poss. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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, now the internal eventfd APIs are using the eventfd context instead
of the file*.
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.
If we really want to squeeze this into 2.6.31 then it would be helpful
to have justification in the changelog, please. I see that some KVM
feature needs it, but what and why and why now, etc?
The patch conflicts with similar changes int he KVM tree, but that'll
just ruin sfr's life for a day.
Your patch has:
...
static int eventfd_release(struct inode *inode, struct file *file)
{
- kfree(file-private_data);
+ struct eventfd_ctx *ctx = file-private_data;
+
+ wake_up_poll(ctx-wqh, POLLHUP);
+ eventfd_ctx_put(ctx);
return 0;
}
but the patch in linux-next has
static int eventfd_release(struct inode *inode, struct file *file)
{
struct eventfd_ctx *ctx = file-private_data;
/*
* No need to hold the lock here, since we are on the file cleanup
* path and the ones still attached to the wait queue will be
* serialized by wake_up_locked_poll().
*/
wake_up_locked_poll(ctx-wqh, POLLHUP);
kfree(ctx);
return 0;
}
which looks quite different (and has a nice comment!)
What's going on here?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009, Andrew Morton wrote: On Tue, 23 Jun 2009 12:25:36 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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, now the internal eventfd APIs are using the eventfd context instead of the file*. 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. If we really want to squeeze this into 2.6.31 then it would be helpful to have justification in the changelog, please. I see that some KVM feature needs it, but what and why and why now, etc? The patch in -next added the ability to have waiters to be notified when the last instance of the file* is dropped (that is, on -release). But it is not possible for waiters to handle the POLLHUP event in a racy-free way, unless the eventfd memory context is de-coupled from the file*. The next patches from gregory will use eventfd (and the POLLHUP handling) to implement the IRQfd code inside KVM. What's going on here? The POLLHUP patch in -next is not sufficent. I based the patch over mainline, but if you guys want I can rebase it over -next. - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 into 2.6.31, it's quite unfortunate to include unrelated changes. Especially ones which involve the always-problematic select. Although this one looks less than usually deadly due to the simple dependencies of AIO and eventfd. However... Is this a good way of fixing the (AIO !EVENTFD) case? Surely if the developer selected this combination, he doesn't want to carry the overhead of including eventfd. IOW, if AIO can work acceptably without eventfd being compiled into the kernel then adding the stubs is a superior solution. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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, now the internal eventfd APIs are using the eventfd context instead
of the file*.
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.
...
+/**
+ * eventfd_ctx_get - Acquires a reference to the internal eventfd context.
+ * @ctx: [in] Pointer to the eventfd context.
+ *
+ * Returns: In case of success, returns a pointer to the eventfd context,
+ * otherwise a proper error code.
The description of the return value
+ */
+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.
Also...
+ * Returns: A pointer to the eventfd file structure in case of success, or a
+ * proper error pointer in case of failure.
+ * Returns: In case of success, it returns a pointer to the internal eventfd
+ * context, otherwise a proper error code.
+ */
I'm unsure what the word proper means in this context.
The term proper error pointer is understandable enough - something
you run IS_ERR() against. error pointer would suffice.
But the term proper error code is getting a bit remote from reality.
Unfortunately the kernel doesn't have a simple and agreed-to term for
an ERR_PTR() thingy. Perhaps we should invent one. err_ptr?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009, Andrew Morton wrote: On Tue, 23 Jun 2009 12:25:36 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 into 2.6.31, it's quite unfortunate to include unrelated changes. Especially ones which involve the always-problematic select. Although this one looks less than usually deadly due to the simple dependencies of AIO and eventfd. However... Is this a good way of fixing the (AIO !EVENTFD) case? Surely if the developer selected this combination, he doesn't want to carry the overhead of including eventfd. IOW, if AIO can work acceptably without eventfd being compiled into the kernel then adding the stubs is a superior solution. IMO when someone says AIO included in the kernel, should get the whole AIO functionality and not part of it. People already started using KAIO+eventfd, and a (AIO !EVENTFD) config will make their code fail. - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009, Andrew Morton wrote:
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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, now the internal eventfd APIs are using the eventfd context instead
of the file*.
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.
...
+/**
+ * eventfd_ctx_get - Acquires a reference to the internal eventfd context.
+ * @ctx: [in] Pointer to the eventfd context.
+ *
+ * Returns: In case of success, returns a pointer to the eventfd context,
+ * otherwise a proper error code.
The description of the return value
Should functions be describing all the returned error codes, ala man pages?
+ */
+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.
Also...
+ * Returns: A pointer to the eventfd file structure in case of success, or
a
+ * proper error pointer in case of failure.
+ * Returns: In case of success, it returns a pointer to the internal
eventfd
+ * context, otherwise a proper error code.
+ */
I'm unsure what the word proper means in this context.
The term proper error pointer is understandable enough - something
you run IS_ERR() against. error pointer would suffice.
But the term proper error code is getting a bit remote from reality.
Unfortunately the kernel doesn't have a simple and agreed-to term for
an ERR_PTR() thingy. Perhaps we should invent one. err_ptr?
OK, but you tricked me once again :)
You posted your comments/changes while you merged the old version in -mm
already.
- Davide
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 13:59:07 -0700 (PDT) Davide Libenzi davi...@xmailserver.org wrote: On Tue, 23 Jun 2009, Andrew Morton wrote: On Tue, 23 Jun 2009 12:25:36 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 into 2.6.31, it's quite unfortunate to include unrelated changes. Especially ones which involve the always-problematic select. Although this one looks less than usually deadly due to the simple dependencies of AIO and eventfd. However... Is this a good way of fixing the (AIO !EVENTFD) case? Surely if the developer selected this combination, he doesn't want to carry the overhead of including eventfd. IOW, if AIO can work acceptably without eventfd being compiled into the kernel then adding the stubs is a superior solution. IMO when someone says AIO included in the kernel, should get the whole AIO functionality and not part of it. People already started using KAIO+eventfd, and a (AIO !EVENTFD) config will make their code fail. That isn't for us to decide. Entire syscalls can be disabled in config. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 14:03:22 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org wrote:
On Tue, 23 Jun 2009, Andrew Morton wrote:
On Tue, 23 Jun 2009 12:25:36 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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, now the internal eventfd APIs are using the eventfd context instead
of the file*.
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.
...
+/**
+ * eventfd_ctx_get - Acquires a reference to the internal eventfd
context.
+ * @ctx: [in] Pointer to the eventfd context.
+ *
+ * Returns: In case of success, returns a pointer to the eventfd context,
+ * otherwise a proper error code.
The description of the return value
Should functions be describing all the returned error codes, ala man pages?
I think so.
+ */
+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 to have not seen the above sentence.
Also...
+ * Returns: A pointer to the eventfd file structure in case of success,
or a
+ * proper error pointer in case of failure.
+ * Returns: In case of success, it returns a pointer to the internal
eventfd
+ * context, otherwise a proper error code.
+ */
I'm unsure what the word proper means in this context.
The term proper error pointer is understandable enough - something
you run IS_ERR() against. error pointer would suffice.
But the term proper error code is getting a bit remote from reality.
Unfortunately the kernel doesn't have a simple and agreed-to term for
an ERR_PTR() thingy. Perhaps we should invent one. err_ptr?
OK, but you tricked me once again :)
You posted your comments/changes while you merged the old version in -mm
already.
yeah, I never trust people. You might lose the email or jump on a
plane and disappear for three weeks, then it all gets forgotten about
and lost.
If the code doesn't have any apparent showstoppers I'll often merge it
with a note that it isn't finalised.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
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 of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
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 to have not seen the above sentence.
I saw that and have already fixed it. Sorry I missed the ACK.
yeah, I never trust people. You might lose the email or jump on a
plane and disappear for three weeks, then it all gets forgotten about
and lost.
Jumping on a plane. Check. Disappearing for 6 weeks. Check. ;)
- Davide
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
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 introduced by the function code, and say that the function returns errors A, B, C plus all the ones returned by the called functions X, Y, Z? If not, it becomes hell in maintaining the comments... - Davide -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 14:25:05 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 what this means, really. AIO eventfd support is a relatively recently added enhancement to AIO, is it not? Applications which continue to use the pre-May07 AIO features will continue to work as before (they darn well better). So for such applications, AIO=y/EVENTFD=n kernels are usable and useful, and eliminating this option is a loss? Either way, I believe that this change should be unbundled from the unrelated KVM one so we can handle it separately. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 14:34:50 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 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 function returns errors A, B, C plus all the ones returned by the called functions X, Y, Z? If not, it becomes hell in maintaining the comments... Well. Don't worry about making rules. Taste and common sense apply. Will it be useful to readers if I explicitly document the return value. If yes then document away. If no then don't. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009, Andrew Morton wrote:
On Tue, 23 Jun 2009 14:34:50 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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 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 function returns errors A, B, C plus all the ones
returned by the called functions X, Y, Z?
If not, it becomes hell in maintaining the comments...
Well. Don't worry about making rules. Taste and common sense apply. Will
it be useful to readers if I explicitly document the return value. If
yes then document away. If no then don't.
Are you OK with the format in the patch below?
- Davide
---
drivers/lguest/lg.h |2
drivers/lguest/lguest_user.c |4 -
fs/aio.c | 24 ++--
fs/eventfd.c | 122 ++-
include/linux/aio.h |4 -
include/linux/eventfd.h | 18 ++
init/Kconfig |1
7 files changed, 129 insertions(+), 46 deletions(-)
Index: linux-2.6.mod/fs/eventfd.c
===
--- linux-2.6.mod.orig/fs/eventfd.c 2009-06-21 16:54:15.0 -0700
+++ linux-2.6.mod/fs/eventfd.c 2009-06-23 14:45:54.0 -0700
@@ -14,35 +14,44 @@
#include linux/list.h
#include linux/spinlock.h
#include linux/anon_inodes.h
-#include linux/eventfd.h
#include linux/syscalls.h
#include linux/module.h
+#include linux/kref.h
+#include linux/eventfd.h
struct eventfd_ctx {
+ struct kref kref;
wait_queue_head_t wqh;
/*
* Every time that a write(2) is performed on an eventfd, the
* value of the __u64 being written is added to count and a
* wakeup is performed on wqh. A read(2) will return the count
* value to userspace, and will reset count to zero. The kernel
-* size eventfd_signal() also, adds to the count counter and
+* side eventfd_signal() also, adds to the count counter and
* issue a wakeup.
*/
__u64 count;
unsigned int flags;
};
-/*
- * Adds n to the eventfd counter count. Returns n in case of
- * success, or a value lower then n in case of coutner overflow.
- * This function is supposed to be called by the kernel in paths
- * that do not allow sleeping. In this function we allow the counter
- * to reach the ULLONG_MAX value, and we signal this as overflow
- * condition by returining a POLLERR to poll(2).
+/**
+ * eventfd_signal - Adds @n to the eventfd counter.
+ * @ctx: [in] Pointer to the eventfd context.
+ * @n: [in] Value of the counter to be added to the eventfd internal counter.
+ * The value cannot be negative.
+ *
+ * This function is supposed to be called by the kernel in paths that do not
+ * allow sleeping. In this function we allow the counter to reach the
ULLONG_MAX
+ * value, and we signal this as overflow condition by returining a POLLERR
+ * to poll(2).
+ *
+ * Returns @n in case of success, a non-negative number lower than @n in case
+ * of overflow, or the following error codes:
+ *
+ * -EINVAL: The value of @n is negative.
*/
-int eventfd_signal(struct file *file, int n)
+int eventfd_signal(struct eventfd_ctx *ctx, int n)
{
- struct eventfd_ctx *ctx = file-private_data;
unsigned long flags;
if (n 0)
@@ -59,9 +68,45 @@ int eventfd_signal(struct file *file, in
}
EXPORT_SYMBOL_GPL(eventfd_signal);
+static void eventfd_free(struct kref *kref)
+{
+ struct eventfd_ctx *ctx = container_of(kref, struct eventfd_ctx, kref);
+
+ kfree(ctx);
+}
+
+/**
+ * eventfd_ctx_get - Acquires a reference to the internal eventfd context.
+ * @ctx: [in] Pointer to the eventfd context.
+ *
+ * Returns: In case of success, returns a pointer to the eventfd context.
+ */
+struct eventfd_ctx *eventfd_ctx_get(struct eventfd_ctx *ctx)
+{
+ kref_get(ctx-kref);
+ return ctx;
+}
+EXPORT_SYMBOL_GPL(eventfd_ctx_get);
+
+/**
+ * eventfd_ctx_put - Releases a reference to the internal eventfd context.
+ * @ctx: [in] Pointer to eventfd context.
+ *
+ * The eventfd context reference must have been previously acquired either
+ * with eventfd_ctx_get() or eventfd_ctx_fdget()).
+ */
+void eventfd_ctx_put(struct eventfd_ctx *ctx)
+{
+ kref_put(ctx-kref, eventfd_free);
+}
+EXPORT_SYMBOL_GPL(eventfd_ctx_put);
+
static int eventfd_release(struct inode *inode, struct file *file)
{
- kfree(file-private_data);
+ struct eventfd_ctx *ctx = file-private_data;
+
+ wake_up_poll(ctx-wqh, POLLHUP);
+ eventfd_ctx_put(ctx);
return 0;
}
@@ -185,6 +230,16 @@ static const struct file_operations even
.write =
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 14:48:51 -0700 (PDT) Davide Libenzi davi...@xmailserver.org 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 function returns errors A, B, C plus all the ones returned by the called functions X, Y, Z? If not, it becomes hell in maintaining the comments... Well. Don't worry about making rules. Taste and common sense apply. Will it be useful to readers if I explicitly document the return value. If yes then document away. If no then don't. Are you OK with the format in the patch below? Looks great to me. Obviously the cost of maintaining this level of detail is fairly high, and the chances of bitrot are also high. So I wouldn't be expecting people to document things at this level in general. But if you're prepared to maintain this then good for you. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009, Andrew Morton wrote:
On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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 what this means, really.
This is the struct iocb:
struct iocb {
...
u_int32_t aio_resfd;
};
And the only interface to access KAIO is io_submit().
IMO the end user perceives the KAIO functionality as the full deployment
of the iocb struct and the io_submit() accessory.
Can code not using eventfd work in (AIO !EVENTFD) mode? Sure.
It is a kinda confusing configuration from the end user POV IMO.
- Davide
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] eventfd - revised interface and cleanups (2nd rev)
On Tue, 23 Jun 2009 15:49:53 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org wrote:
On Tue, 23 Jun 2009, Andrew Morton wrote:
On Tue, 23 Jun 2009 14:25:05 -0700 (PDT)
Davide Libenzi davi...@xmailserver.org 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 what this means, really.
This is the struct iocb:
struct iocb {
...
u_int32_t aio_resfd;
};
And the only interface to access KAIO is io_submit().
IMO the end user perceives the KAIO functionality as the full deployment
of the iocb struct and the io_submit() accessory.
Can code not using eventfd work in (AIO !EVENTFD) mode? Sure.
It is a kinda confusing configuration from the end user POV IMO.
What's confusing about it?
Most programmers who are using AIO probably don't even know that the
eventd hookup is available. And even if they did, they might not want
to use it, to remain compatible with older kernels.
I'm still not seeing any compelling reason for unconditionally adding
kernel text which some users don't need.
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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
