kevent: Generic event handling mechanism.

Timer notifications.

Timer notifications can be used for fine grained per-process time management, since interval timers are very inconvenient to use, and they are limited.

kernel/kevent/kevent_timer.c new file +7 -0

+static struct lock_class_key kevent_timer_key;
+
+static int kevent_timer_enqueue(struct kevent *k)
+{
+	int err;
+	struct kevent_timer *t;
+

Quoted 7 lines · Evgeniy Polyakov

Timer notifications.

Timer notifications can be used for fine grained per-process time management, since interval timers are very inconvenient to use, and they are limited.

Shouldn't this at leat use a hrtimer?

kernel/kevent/kevent_timer.c line 2

Quoted 7 lines

new file mode 100644
index 0000000..5217cd1

kernel/kevent/kevent_timer.c new file +2 -0

@@ -0,0 +1,107 @@
+/*
+ * 	kevent_timer.c

You still include those sill filename ontop of file comments..

Quoted 13 lines

kernel/kevent/kevent_timer.c new file +13 -0

+static struct lock_class_key kevent_timer_key;
+
+static int kevent_timer_enqueue(struct kevent *k)
+{
+	int err;
+	struct kevent_timer *t;
+
+	t = kmalloc(sizeof(struct kevent_timer), GFP_KERNEL);
+	if (!t)
+		return -ENOMEM;
+
+	setup_timer(&t->ktimer, &kevent_timer_func, (unsigned long)k);
+

kernel/kevent/kevent_timer.c line 62

Quoted 4 lines

kernel/kevent/kevent_timer.c new file +4 -0

+	err = kevent_storage_init(&t->ktimer, &t->ktimer_storage);
+	if (err)
+		goto err_out_free;
+	lockdep_set_class(&t->ktimer_storage.lock, &kevent_timer_key);

When looking at the kevent_storage_init callers most need to do those lockdep_set_class class. Shouldn't kevent_storage_init just get a "struct lock_class_key *" argument?

kernel/kevent/kevent_timer.c line 94

Quoted 3 lines

kernel/kevent/kevent_timer.c new file +3 -0

+static int kevent_timer_callback(struct kevent *k)
+{
+	k->event.ret_data[0] = (__u32)jiffies;

This is returned to userspace, isn't it? raw jiffies should never be user-visible. Please convert this to an unit that actually makes sense for userspace (probably nanoseconds)

kernel/kevent/kevent_timer.c line 103

Quoted 6 lines

kernel/kevent/kevent_timer.c new file +6 -0

+static int __init kevent_init_timer(void)
+{
+	struct kevent_callbacks tc = {
+		.callback = &kevent_timer_callback, 
+		.enqueue = &kevent_timer_enqueue, 
+		.dequeue = &kevent_timer_dequeue};

I think this should be static, and the normal style to write it would be:

static struct kevent_callbacks tc = {
.callback = kevent_timer_callback,
.enqueue = kevent_timer_enqueue,
.dequeue = kevent_timer_dequeue,
};

also please consider makring all the kevent_callbacks structs const to avoid false cacheline sharing and accidental modification, similar to what we did to various other operation vectors.

]> > + lockdep_set_class(&t->ktimer_storage.lock, &kevent_timer_key);

Quoted 4 lines

When looking at the kevent_storage_init callers most need to do those lockdep_set_class class. Shouldn't kevent_storage_init just get a "struct lock_class_key *" argument?

It will not work, since inode is used for both socket and inode notifications (to save some space in struct sock), lockdep initalization is performed on the highest level, so I put it alone.

Quoted 6 lines · Evgeniy Polyakov

]> > + lockdep_set_class(&t->ktimer_storage.lock, &kevent_timer_key);

Quoted 4 lines

When looking at the kevent_storage_init callers most need to do those lockdep_set_class class. Shouldn't kevent_storage_init just get a "struct lock_class_key *" argument?

Quoted 3 lines

It will not work, since inode is used for both socket and inode notifications (to save some space in struct sock), lockdep initalization is performed on the highest level, so I put it alone.

Call me a cynic, but I'm always a bit sceptical about needing lockdep annotations like this... Can you explain why you need it in this case, including the proof that it's safe?

Quoted 7 lines · Arjan van de Ven

Quoted 6 lines · Evgeniy Polyakov

]> > + lockdep_set_class(&t->ktimer_storage.lock, &kevent_timer_key);

Quoted 4 lines

When looking at the kevent_storage_init callers most need to do those lockdep_set_class class. Shouldn't kevent_storage_init just get a "struct lock_class_key *" argument?

Quoted 7 lines

Quoted 3 lines

It will not work, since inode is used for both socket and inode notifications (to save some space in struct sock), lockdep initalization is performed on the highest level, so I put it alone.

Call me a cynic, but I'm always a bit sceptical about needing lockdep annotations like this... Can you explain why you need it in this case, including the proof that it's safe?

Ok, again :)
Kevent uses meaning of storage of kevents without any special knowledge what is is (inode, socket, file, timer - anything), so it's initalization function among other things calls spin_lock_init(). Lockdep inserts static variable just before real spinlock initialization, and since all locks are initialized in the same place, all of them get the same static magic.
Later those locks are used in different context (for example inode notificatins only in process context, but socket can be called from BH context), since lockdep thinks they are the same, it screams. Obviously the same inode can not be used for sockets and files, so I added above lockdep initialization.

Quoted 4 lines

Quoted 3 lines

Call me a cynic, but I'm always a bit sceptical about needing lockdep annotations like this... Can you explain why you need it in this case, including the proof that it's safe?

Quoted 12 lines

Ok, again :)
Kevent uses meaning of storage of kevents without any special knowledge what is is (inode, socket, file, timer - anything), so it's initalization function among other things calls spin_lock_init(). Lockdep inserts static variable just before real spinlock initialization, and since all locks are initialized in the same place, all of them get the same static magic.
Later those locks are used in different context (for example inode notificatins only in process context, but socket can be called from BH context), since lockdep thinks they are the same, it screams. Obviously the same inode can not be used for sockets and files, so I added above lockdep initialization.

ok... but since kevent doesn't know what is in it, wouldn't the locking rules need to be such that it can deal with the "worst case" event? Eg do you really have both no knowledge of what is inside, and specific locking implementations for the different types of content??? That sounds rather error prone.....
(if you had consistent locking rules lockdep would be perfectly fine with that)

Signature · 1 line

if you want to mail me at work (you don't), use arjan (at) linux.intel.com

Quoted 5 lines · Christoph Hellwig

Quoted 4 lines · Evgeniy Polyakov

Timer notifications.

Quoted 5 lines

Quoted 3 lines

Timer notifications can be used for fine grained per-process time management, since interval timers are very inconvenient to use, and they are limited.

Shouldn't this at leat use a hrtimer?

Not everymachine has them

and getting into account possibility that userspace can be scheduled away, it will be overkill.

Quoted 1 line

Not everymachine has them

Every machine has hrtimers - not necessarily with high resolution timer support, but the core code is there in any case and it is designed to provide fine grained timers.

In case of high resolution time support one would expect that the "fine grained" timer event is actually fine grained.

Quoted 2 lines

and getting into account possibility that userspace can be scheduled away, it will be overkill.

If you think out your argument then everything which is fine grained or high responsive should be removed from userspace access for the very same reason. Please look at the existing users of the hrtimer subsystem
- all of them are exposed to userspace.

tglx

kernel/kevent/kevent_timer.c line 103

Quoted 6 lines

kernel/kevent/kevent_timer.c new file +6 -0

+static int __init kevent_init_timer(void)
+{
+	struct kevent_callbacks tc = {
+		.callback = &kevent_timer_callback, 
+		.enqueue = &kevent_timer_enqueue, 
+		.dequeue = &kevent_timer_dequeue};

I think this should be static, and the normal style to write it would be:

static struct kevent_callbacks tc = {
.callback = kevent_timer_callback,
.enqueue = kevent_timer_enqueue,
.dequeue = kevent_timer_dequeue,
};

also please consider makring all the kevent_callbacks structs const to avoid false cacheline sharing and accidental modification, similar to what we did to various other operation vectors.

Quoted 15 lines · Christoph Hellwig

kernel/kevent/kevent_timer.c line 103

Quoted 6 lines

kernel/kevent/kevent_timer.c new file +6 -0

+static int __init kevent_init_timer(void)
+{
+	struct kevent_callbacks tc = {
+		.callback = &kevent_timer_callback, 
+		.enqueue = &kevent_timer_enqueue, 
+		.dequeue = &kevent_timer_dequeue};

I think this should be static, and the normal style to write it would be:

static struct kevent_callbacks tc = {
.callback = kevent_timer_callback,
.enqueue = kevent_timer_enqueue,
.dequeue = kevent_timer_dequeue,
};

Quoted 3 lines

also please consider makring all the kevent_callbacks structs const to avoid false cacheline sharing and accidental modification, similar to what we did to various other operation vectors.

Actually I do not think it should be static, since it is only used for initialization and it's members are copied into main structure.

Quoted 16 lines · On Mon, 21 Aug 2006 16:09:34 +0400 Evgeniy Polyakov <[email protected]> wrote:

Quoted 15 lines · Christoph Hellwig

kernel/kevent/kevent_timer.c line 103

Quoted 6 lines

kernel/kevent/kevent_timer.c new file +6 -0

+static int __init kevent_init_timer(void)
+{
+	struct kevent_callbacks tc = {
+		.callback = &kevent_timer_callback, 
+		.enqueue = &kevent_timer_enqueue, 
+		.dequeue = &kevent_timer_dequeue};

I think this should be static, and the normal style to write it would be:

static struct kevent_callbacks tc = {
.callback = kevent_timer_callback,
.enqueue = kevent_timer_enqueue,
.dequeue = kevent_timer_dequeue,
};

Quoted 7 lines

Quoted 3 lines

also please consider makring all the kevent_callbacks structs const to avoid false cacheline sharing and accidental modification, similar to what we did to various other operation vectors.

Actually I do not think it should be static, since it is only used for initialization and it's members are copied into main structure.

It should be static __initdata a) so we don't need to construct it at runtime and b) so it gets dropped from memory after initcalls have run.

(But given that kevent_init_timer() also gets dropped from memory after initcalls it hardly matters).

Hello Evgeniy

I have one comment/suggestion (minor detail, your work is very good)

I suggest to add one item in kevent_registered_callbacks[], so that kevent_registered_callbacks[KEVENT_MAX] is valid and can act as a fallback.

Eric Dumazet

On Wed, Aug 23, 2006 at 10:51:36AM +0200, Eric Dumazet ([email protected])

Quoted 1 line

Hello Evgeniy

Hi Eric.

Quoted 5 lines

I have one comment/suggestion (minor detail, your work is very good)

I suggest to add one item in kevent_registered_callbacks[], so that kevent_registered_callbacks[KEVENT_MAX] is valid and can act as a fallback.

Sounds good, could you please send appliable patch with proper signed-off line?

Quoted 2 lines

Sounds good, could you please send appliable patch with proper signed-off line?

Unfortunately not at this moment, I'm quite busy at work, my boss will kill me :( .
If you find this good, please add it to your next patch submission or forget it.

Thank you
Eric

Generic event handling mechanism.

Quoted 1 line · Evgeniy Polyakov

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 are now just backward compatibility bloat.)

Just looking at the proposed kevent API, it appears that the timer event queuing mechanism can't be used for the queuing of POSIX.1b interval timer events (i.e. via a SIGEV_KEVENT notification value in a struct sigevent) because (being a very thin veneer over the internal kernel timer system) you can't specify a clockid, the time value doesn't have the flexibility of a struct itimerspec (no re-arm timeout or absolute times), and there's no way to alter, disable or query a pending timer or query a timer overrun count.

Overall, kevent timers appear to be inconvenient to use and limited compared to POSIX interval timers (excepting the fact you can read their expiray events out of a queue, of course).

[1] Previously: select, poll, AIO, epoll, and inotify. Did I miss any?

Signature · 1 line

Nicholas Miell <[email protected]>

Quoted 17 lines · Nicholas Miell

Quoted 1 line · Evgeniy Polyakov

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 are now just backward compatibility bloat.)

Just looking at the proposed kevent API, it appears that the timer event queuing mechanism can't be used for the queuing of POSIX.1b interval timer events (i.e. via a SIGEV_KEVENT notification value in a struct sigevent) because (being a very thin veneer over the internal kernel timer system) you can't specify a clockid, the time value doesn't have the flexibility of a struct itimerspec (no re-arm timeout or absolute times), and there's no way to alter, disable or query a pending timer or query a timer overrun count.

Quoted 3 lines

Overall, kevent timers appear to be inconvenient to use and limited compared to POSIX interval timers (excepting the fact you can read their expiry events out of a queue, of course).

Kevent timers are just trivial kevent user.
But even as is it is not that bad solution.
I, as user, do not want to know which timer is used - I only need to get some signal when interval completed, especially I do not want to have some troubles when timer with given clockid has disappeared. Kevent timer can be trivially rearmed (acutally it is always rearmed until one-shot flag is set).
Of course it can be disabled by removing requested kevent.
I can add possibility to alter timeout without removing kevent if there is strong requirement for that.

Timer notifications were designed not from committee point of view, when theoretical discussions end up in multi-megabyte documentation 99.9% of which can not be used without major brain surgery.

I just implemented what I use, if you want more - say what you need.

Quoted 2 lines

[1] Previously: select, poll, AIO, epoll, and inotify. Did I miss any?

Let me guess - kevent, which can do all above and a lot of other things? And you forget netlink-based notificators - netlink, rtnetlink, gennetlink, connector and tons of accounting application based on them, kobject, kobject_uevent.
There also filessytem based ones - sysfs, procfs, debugfs, relayfs.

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 problems.

From: Nicholas Miell <[email protected]>
Date: Tue, 22 Aug 2006 01:17:52 -0700

Quoted 4 lines

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 problems.

Get real.

Nobody made this requirement for things like splice() et al.

I think people are being mostly very unreasonable in the demands they are making upon Evgeniy. It will only serve to discourage the one person who is doing work to solve these problems.

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 is supposed to work and demonstrating how it will be used, then mistakes are bound to slip through.

Quoted 6 lines · Nicholas Miell

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 is supposed to work and demonstrating how it will be used, then mistakes are bound to slip through.

Feel free to provide the documentation. Perhaps, even as much as you've written so far in these emails would be enough.

I'm not the one proposing the new (potentially wrong) interface. The onus isn't on me.

From: Nicholas Miell <[email protected]>
Date: Tue, 22 Aug 2006 13:00:23 -0700

Quoted 2 lines

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 can't complain.

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 stable kernel release?

From: Nicholas Miell <[email protected]>
Date: Tue, 22 Aug 2006 14:13:40 -0700

Quoted 4 lines

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 stable kernel release?

Are you even willing to look at the collection of example applications Evgeniy wrote against this API?

That is the true test of a set of interfaces, what happens when you try to actually use them in real programs.

Everything else is fluff, including standards and "documentation".

He even bothered to benchmark things, and post assosciated graphs and performance analysis during the course of development.

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 only file descriptors and AIO but also timers, signals, message queues (OK, they are file descriptors but let's make it official), futexes. I'm probably missing the one or the other thing now.

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 write up my recommendations re the interface before Monday.

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 write up my recommendations re the interface before Monday.

Signature · 1 line

➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Quoted 22 lines · Evgeniy Polyakov

Quoted 17 lines · Nicholas Miell

Quoted 1 line · Evgeniy Polyakov

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 are now just backward compatibility bloat.)

Just looking at the proposed kevent API, it appears that the timer event queuing mechanism can't be used for the queuing of POSIX.1b interval timer events (i.e. via a SIGEV_KEVENT notification value in a struct sigevent) because (being a very thin veneer over the internal kernel timer system) you can't specify a clockid, the time value doesn't have the flexibility of a struct itimerspec (no re-arm timeout or absolute times), and there's no way to alter, disable or query a pending timer or query a timer overrun count.

Quoted 3 lines

Overall, kevent timers appear to be inconvenient to use and limited compared to POSIX interval timers (excepting the fact you can read their expiry events out of a queue, of course).

Quoted 11 lines

Kevent timers are just trivial kevent user.
But even as is it is not that bad solution.
I, as user, do not want to know which timer is used - I only need to get some signal when interval completed, especially I do not want to have some troubles when timer with given clockid has disappeared. Kevent timer can be trivially rearmed (acutally it is always rearmed until one-shot flag is set).
Of course it can be disabled by removing requested kevent.
I can add possibility to alter timeout without removing kevent if there is strong requirement for that.

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 problems.

Quoted 3 lines

Timer notifications were designed not from committee point of view, when theoretical discussions end up in multi-megabyte documentation 99.9% of which can not be used without major brain surgery.

Do you have any technical objections to the POSIX.1b interval timer design to back up your insults?

Quoted 1 line

I just implemented what I use, if you want more - say what you need.

I don't know what I need, I just know what POSIX already has, and your

extensions don't appear to be compatible with that model and deliberately designing something that has no hope of ever getting into the POSIX standard or serving as the basis for whatever comes out of the standard committee seems rather stupid. (Especially considering that Linux's only viable competitor has already shipped a unified event queuing API that does fit into the existing POSIX design.)

Ulrich Drepper is probably better able to speak on this than I am, considering that he's involved with POSIX and is probably going to be involved in the Linux libc work, whatever it may be.

Quoted 8 lines

Quoted 2 lines

[1] Previously: select, poll, AIO, epoll, and inotify. Did I miss any?

Let me guess - kevent, which can do all above and a lot of other things? And you forget netlink-based notificators - netlink, rtnetlink, gennetlink, connector and tons of accounting application based on them, kobject, kobject_uevent.
There also filessytem based ones - sysfs, procfs, debugfs, relayfs.

OK, so with literally a dozen different interfaces to queue events to userspace, all of which are apparently inadequate and in need of replacement by kevent, don't you want to slow down a bit and make sure that the kevent API is correct before it becomes permanent and then just has to be replaced *again* ?

Signature · 1 line

Nicholas Miell <[email protected]>

Quoted 35 lines · Nicholas Miell

Quoted 33 lines · Evgeniy Polyakov

Quoted 17 lines · Nicholas Miell

Quoted 1 line · Evgeniy Polyakov

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 are now just backward compatibility bloat.)

Just looking at the proposed kevent API, it appears that the timer event queuing mechanism can't be used for the queuing of POSIX.1b interval timer events (i.e. via a SIGEV_KEVENT notification value in a struct sigevent) because (being a very thin veneer over the internal kernel timer system) you can't specify a clockid, the time value doesn't have the flexibility of a struct itimerspec (no re-arm timeout or absolute times), and there's no way to alter, disable or query a pending timer or query a timer overrun count.

Quoted 3 lines

Overall, kevent timers appear to be inconvenient to use and limited compared to POSIX interval timers (excepting the fact you can read their expiry events out of a queue, of course).

Kevent timers are just trivial kevent user.
But even as is it is not that bad solution.
I, as user, do not want to know which timer is used - I only need to get some signal when interval completed, especially I do not want to have some troubles when timer with given clockid has disappeared. Kevent timer can be trivially rearmed (acutally it is always rearmed until one-shot flag is set).
Of course it can be disabled by removing requested kevent.
I can add possibility to alter timeout without removing kevent if there is strong requirement for that.

Quoted 4 lines

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 problems.

There are two excellent articles on lwn.net

Quoted 6 lines

OK, so with literally a dozen different interfaces to queue events to userspace, all of which are apparently inadequate and in need of replacement by kevent, don't you want to slow down a bit and make sure that the kevent API is correct before it becomes permanent and then just has to be replaced *again* ?

I only though that license issues remains unresolved in that linux-kernel@ flood, but not, I was wrong :)

I will ask just one question, do _you_ propose anything here?

Quoted 6 lines

Quoted 4 lines

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 problems.

There are two excellent articles on lwn.net

Google knows of one and it doesn't actually explain how to use kevents.

Quoted 2 lines

I will ask just one question, do _you_ propose anything here?

struct sigevent sigev = {
.sigev_notify = SIGEV_KEVENT,
.sigev_kevent_fd = kev_fd,
.sigev_value.sival_ptr = &MyCookie
};

struct itimerspec its = {
	.it_value = { ... },
	.it_interval = { ... }
};

struct timespec timeout = { .. };

struct ukevent events[max];

timer_t timer;

timer_create(CLOCK_MONOTONIC, &sigev, &timer);
timer_settime(timer, 0, &its, NULL);

/* ... */

kevent_get_events(kev_fd, min, max, &timeout, events, 0);

Which isn't all that different from what Ulrich Drepper suggested and Solaris does right now. (timer_create would probably end up calling kevent_ctl itself, but it obviously can't do that unless kevents actually support real interval timers).

Signature · 1 line

Nicholas Miell <[email protected]>

Quoted 7 lines · Nicholas Miell

Quoted 6 lines

Quoted 4 lines

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 problems.

There are two excellent articles on lwn.net

Quoted 1 line

Google knows of one and it doesn't actually explain how to use kevents.

http://lwn.net/Articles/192964/
http://lwn.net/Articles/172844/

In the thread there were enough links to homepage where you can find several examples of how to use kevents (and timers among others) with old interfaces and new ones.

Quoted 25 lines

Quoted 2 lines

I will ask just one question, do _you_ propose anything here?

struct sigevent sigev = {
.sigev_notify = SIGEV_KEVENT,
.sigev_kevent_fd = kev_fd,
.sigev_value.sival_ptr = &MyCookie
};

struct itimerspec its = {
	.it_value = { ... },
	.it_interval = { ... }
};

struct timespec timeout = { .. };

struct ukevent events[max];

timer_t timer;

timer_create(CLOCK_MONOTONIC, &sigev, &timer);
timer_settime(timer, 0, &its, NULL);

/* ... */

Quoted 8 lines

kevent_get_events(kev_fd, min, max, &timeout, events, 0);

Which isn't all that different from what Ulrich Drepper suggested and Solaris does right now. (timer_create would probably end up calling kevent_ctl itself, but it obviously can't do that unless kevents actually support real interval timers).

Ugh, rtsignals... Their's problems forced me to not implement "interrupt"-like mechanism for kevents in addition to dequeueing.

Anyway, it seems you did not read the whole thread, homepage, lwn and userpsace examples, so you do not understand what kevents are.

They are userspace requests which are returned back when they are ready. It means that userspace must provide something to kernel and ask it to notify when that "something" is ready. For example it can provide a timeout value and ask kernel to fire a timer with it and inform userspace when timeout has expired.
It does not matter what timer is used there - feel free to use high-resolution one, usual timer, busyloop or anything else. Main issue that userspace request must be completed.

What you are trying to do is to put kevents under POSIX API. That means that those kevents can not be read using kevent_get_events(), basicaly because there are no user-known kevents, i.e. user has not requested timer, so it should not receive it's notifications (otherwise it will receive everything requested by other threads and other issues, i.e. how to differentiate timer request made by timer_create(), which is not supposed to be caught by kevent_get_events()).

You could implement POSIX timer _fully_ on top of kevents, i.e. both create and read, for example network AIO is implemented in that way - there is a system calls aio_send()/aio_recv() and aio_sendfile() which create kevent internally and then get it's readiness notifications over provided callback, process data and finally remove kevent, so POSIX timers could create timer kevent, wait until it is ready, in completeness callback it would call signal delivering mechanism...

But there are no reading mechanism in POSIX timers (I mean not reading pending timeout values or remaining time), they use signals for completeness delivering... So where do you want to put kevent's userspace there?

What you are trying to achive is not POSIX timers in any way, you want completely new machanism which has similar to POSIX API, and I give it to you (well, with API which can be used not only with timers, but with any other type of notifications you like).
You need clockid_t? Put it in raw.id[0] and make kevent_timer_enqueue() callback select different type of timers.
What else?

Quoted 8 lines · Evgeniy Polyakov

Quoted 7 lines · Nicholas Miell

Quoted 6 lines

Quoted 4 lines

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 problems.

There are two excellent articles on lwn.net

Quoted 9 lines

Quoted 1 line

Google knows of one and it doesn't actually explain how to use kevents.

http://lwn.net/Articles/192964/
http://lwn.net/Articles/172844/

In the thread there were enough links to homepage where you can find several examples of how to use kevents (and timers among others) with old interfaces and new ones.

Oh, I found both of those. Neither of them told me what values I could use in a struct kevent_user_control or what they meant or what any of the fields in a struct ukevent or struct kevent_id meant or what I'm supposed to pass in kevent_get_event's "void* buf", or many other things that I don't remember now.

In short, I'm stuck trying to reverse engineer from the source what the API is supposed to be (which might not even be what is actually implemented due to the as of yet unfound bug).

Of course, since you already know how all this stuff is supposed to work, you could maybe write it down somewhere?

Quoted 50 lines

Quoted 26 lines

Quoted 3 lines

I will ask just one question, do _you_ propose anything here?

struct sigevent sigev = {
.sigev_notify = SIGEV_KEVENT,
.sigev_kevent_fd = kev_fd,
.sigev_value.sival_ptr = &MyCookie
};

struct itimerspec its = {
	.it_value = { ... },
	.it_interval = { ... }
};

struct timespec timeout = { .. };

struct ukevent events[max];

timer_t timer;

timer_create(CLOCK_MONOTONIC, &sigev, &timer);
timer_settime(timer, 0, &its, NULL);

/* ... */

Quoted 8 lines

kevent_get_events(kev_fd, min, max, &timeout, events, 0);

Which isn't all that different from what Ulrich Drepper suggested and Solaris does right now. (timer_create would probably end up calling kevent_ctl itself, but it obviously can't do that unless kevents actually support real interval timers).

Ugh, rtsignals... Their's problems forced me to not implement "interrupt"-like mechanism for kevents in addition to dequeueing.

Anyway, it seems you did not read the whole thread, homepage, lwn and userpsace examples, so you do not understand what kevents are.

They are userspace requests which are returned back when they are ready. It means that userspace must provide something to kernel and ask it to notify when that "something" is ready. For example it can provide a timeout value and ask kernel to fire a timer with it and inform userspace when timeout has expired.
It does not matter what timer is used there - feel free to use high-resolution one, usual timer, busyloop or anything else. Main issue that userspace request must be completed.

Quoted 9 lines

What you are trying to do is to put kevents under POSIX API. That means that those kevents can not be read using kevent_get_events(), basicaly because there are no user-known kevents, i.e. user has not requested timer, so it should not receive it's notifications (otherwise it will receive everything requested by other threads and other issues, i.e. how to differentiate timer request made by timer_create(), which is not supposed to be caught by kevent_get_events()).

I have no idea what you're trying to say here. I've created a timer, specified which kevent queue I want it's expiry notification delivered to, and armed it. Where have I not specified enough information to request the reception of timer notifications?

Also, differentiating timers made by timer_create() that aren't supposed to deliver events via kevent_get_events() is easy -- their .sigev_notify isn't SIGEV_KEVENT.

Quoted 8 lines

You could implement POSIX timer _fully_ on top of kevents, i.e. both create and read, for example network AIO is implemented in that way - there is a system calls aio_send()/aio_recv() and aio_sendfile() which create kevent internally and then get it's readiness notifications over provided callback, process data and finally remove kevent, so POSIX timers could create timer kevent, wait until it is ready, in completeness callback it would call signal delivering mechanism...

Yes, but that would be stupid. The kernel already has a fully functional POSIX timer implementation, so throwing it out to reimplement it using kevents would be a waste of effort, especially considering that your kevent timers can't fully express a POSIX interval timer.

Now, if there were some way for me to ask that an interval timer queue it's expiry notices into a kevent queue, that would combine the best of both worlds.

Quoted 5 lines

But there are no reading mechanism in POSIX timers (I mean not reading pending timeout values or remaining time), they use signals for completeness delivering... So where do you want to put kevent's userspace there?

The goal of this proposal is to extend sigevent completions to include kevent queues along with signals and created threads, exactly because thread creation is too heavy and signals are a pain to use.

Quoted 7 lines

What you are trying to achive is not POSIX timers in any way, you want completely new machanism which has similar to POSIX API, and I give it to you (well, with API which can be used not only with timers, but with any other type of notifications you like).
You need clockid_t? Put it in raw.id[0] and make kevent_timer_enqueue() callback select different type of timers.
What else?

No, it's still POSIX timers -- the vast majority of the API is the same, they just report their completion differently.

Signature · 1 line

Nicholas Miell <[email protected]>

Quoted 3 lines · Nicholas Miell

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 could maybe write it down somewhere?

I will write documantation, but as you can see some interfaces are changed.

Quoted 57 lines

Quoted 56 lines

Quoted 24 lines

Quoted 1 line

I will ask just one question, do _you_ propose anything here?

struct sigevent sigev = {
.sigev_notify = SIGEV_KEVENT,
.sigev_kevent_fd = kev_fd,
.sigev_value.sival_ptr = &MyCookie
};

struct itimerspec its = {
	.it_value = { ... },
	.it_interval = { ... }
};

struct timespec timeout = { .. };

struct ukevent events[max];

timer_t timer;

timer_create(CLOCK_MONOTONIC, &sigev, &timer);
timer_settime(timer, 0, &its, NULL);

/* ... */

Quoted 8 lines

kevent_get_events(kev_fd, min, max, &timeout, events, 0);

Which isn't all that different from what Ulrich Drepper suggested and Solaris does right now. (timer_create would probably end up calling kevent_ctl itself, but it obviously can't do that unless kevents actually support real interval timers).

Ugh, rtsignals... Their's problems forced me to not implement "interrupt"-like mechanism for kevents in addition to dequeueing.

Anyway, it seems you did not read the whole thread, homepage, lwn and userpsace examples, so you do not understand what kevents are.

They are userspace requests which are returned back when they are ready. It means that userspace must provide something to kernel and ask it to notify when that "something" is ready. For example it can provide a timeout value and ask kernel to fire a timer with it and inform userspace when timeout has expired.
It does not matter what timer is used there - feel free to use high-resolution one, usual timer, busyloop or anything else. Main issue that userspace request must be completed.

What you are trying to do is to put kevents under POSIX API. That means that those kevents can not be read using kevent_get_events(), basicaly because there are no user-known kevents, i.e. user has not requested timer, so it should not receive it's notifications (otherwise it will receive everything requested by other threads and other issues, i.e. how to differentiate timer request made by timer_create(), which is not supposed to be caught by kevent_get_events()).

Quoted 4 lines

I have no idea what you're trying to say here. I've created a timer, specified which kevent queue I want it's expiry notification delivered to, and armed it. Where have I not specified enough information to request the reception of timer notifications?

You can do it with kevent timer notifications. Easily. I've even attached simple program for that.

Quoted 3 lines

Also, differentiating timers made by timer_create() that aren't supposed to deliver events via kevent_get_events() is easy -- their .sigev_notify isn't SIGEV_KEVENT.

What should be returned to user?
What should be placed into user's data, into id?

How user can determine that given event fires after which initial value?

Finally, if you think that kevents should use different API for different events, think about complicated userspace code which must know tons of syscalls for the same task.

Quoted 13 lines

Quoted 7 lines

You could implement POSIX timer _fully_ on top of kevents, i.e. both create and read, for example network AIO is implemented in that way - there is a system calls aio_send()/aio_recv() and aio_sendfile() which create kevent internally and then get it's readiness notifications over provided callback, process data and finally remove kevent, so POSIX timers could create timer kevent, wait until it is ready, in completeness callback it would call signal delivering mechanism...

Yes, but that would be stupid. The kernel already has a fully functional POSIX timer implementation, so throwing it out to reimplement it using kevents would be a waste of effort, especially considering that your kevent timers can't fully express a POSIX interval timer.

Quoted 3 lines

Now, if there were some way for me to ask that an interval timer queue it's expiry notices into a kevent queue, that would combine the best of both worlds.

Just use kevents directly without POSIX timers at all. It is possible to add there high-resolution timers.

Quoted 8 lines

Quoted 4 lines

But there are no reading mechanism in POSIX timers (I mean not reading pending timeout values or remaining time), they use signals for completeness delivering... So where do you want to put kevent's userspace there?

The goal of this proposal is to extend sigevent completions to include kevent queues along with signals and created threads, exactly because thread creation is too heavy and signals are a pain to use.

What you propose is completely new mechanism - it is implemented inside kevent timer notifications expect that API does not match POSIX one.

Quoted 8 lines

Quoted 7 lines

What you are trying to achive is not POSIX timers in any way, you want completely new machanism which has similar to POSIX API, and I give it to you (well, with API which can be used not only with timers, but with any other type of notifications you like).
You need clockid_t? Put it in raw.id[0] and make kevent_timer_enqueue() callback select different type of timers.
What else?

Quoted 2 lines

No, it's still POSIX timers -- the vast majority of the API is the same, they just report their completion differently.

POSIX timers are just a API over in-kernel timers.
Kevent provides different and much more convenient API (since you want to not use signals but kevent's queue), so where are those similar things?

How will you change a timer from POSIX syscall, when it completely does not know about kevents, there will be racess, so you need to change POSIX API (it's internal part which works with timers).

If you are going to change internal part of POSIX timers implementatin and add new syscall into your userspace program, you can just switch to the new API entirely, since right now I do not see any major problems in kevent timer implementation (expect that it does not use high-res timers, which were not included into kernel when kevents were created).

Quoted 5 lines · Evgeniy Polyakov

Quoted 3 lines · Nicholas Miell

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 could maybe write it down somewhere?

Quoted 2 lines

I will write documantation, but as you can see some interfaces are changed.

Thanks; rapidly changing interfaces need good documentation even more than stable interfaces simply because reverse engineering the intended API from a changing implementation becomes even more difficult.

Quoted 6 lines · On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:

Quoted 5 lines · Evgeniy Polyakov

Quoted 3 lines · Nicholas Miell

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 could maybe write it down somewhere?

Quoted 6 lines

Quoted 2 lines

I will write documantation, but as you can see some interfaces are changed.

Thanks; rapidly changing interfaces need good documentation even more than stable interfaces simply because reverse engineering the intended API from a changing implementation becomes even more difficult.

OK, I don't quite get it.
Can you be precise about what you would like?

a.  good documentation
b.  a POSIX API
c.  a Windows-compatible API
d.  other?

and we won't make you use any of this code.

If there _is_ something wrong with kqueue then let us identify those weaknesses and then diverge.

From: Andrew Morton <[email protected]>
Date: Tue, 22 Aug 2006 15:01:44 -0700

Quoted 2 lines

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.

Quoted 6 lines · On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:

Quoted 5 lines · Evgeniy Polyakov

Quoted 3 lines · Nicholas Miell

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 could maybe write it down somewhere?

Quoted 6 lines

Quoted 2 lines

I will write documantation, but as you can see some interfaces are changed.

Thanks; rapidly changing interfaces need good documentation even more than stable interfaces simply because reverse engineering the intended API from a changing implementation becomes even more difficult.

OK, I don't quite get it.
Can you be precise about what you would like?

a.  good documentation
b.  a POSIX API
c.  a Windows-compatible API
d.  other?

and we won't make you use any of this code.

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 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 problems with them.

You choose to rant and complain instead of participate.

Therefore, many of us cannot take you seriously.

Having looked all this over to figure out what it actually does, I can make the following comments:

- there's a distinct lack of any sort of commenting beyond brief descriptions of what the occasional function is supposed to do

- the kevent interface is all the horror of the BSD kqueue interface, but with no compatibility with the BSD kqueue interface.

- lots of parameters from userspace go unsanitized, although I'm not sure if this will actually cause problems. At the very least, there should be checks for unknown flags and use of reserved fields, lest somebody start using them for their own purposes and then their app breaks when a newer version of the kernel starts using them itself.

Dear DaveM,

Go fuck yourself.

From: Nicholas Miell <[email protected]>
Date: Tue, 22 Aug 2006 18:36:07 -0700

Quoted 3 lines

Dear DaveM,

Go fuck yourself.

I guess this is the bit that's supposed to make me take you seriously :-)

Quoted 3 lines · David Miller

From: Nicholas Miell <[email protected]>
Date: Tue, 22 Aug 2006 18:36:07 -0700

Quoted 6 lines

Quoted 3 lines

Dear DaveM,

Go fuck yourself.

I guess this is the bit that's supposed to make me take you seriously :-)

Of course. ^_^

== 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 fact to the FreeBSD/OS X kqueue interface.

Using a single kernel call, a thread can wait for all possible event types that the kernel can generate, instead of past interfaces that only allow you to wait for specific subsets of events (e.g. POSIX sigevent completions are limited only to AIO completion, timer expiry, and the arrival of new messages to a message queue, while epoll_wait is just a more efficient method of doing a traditional Unix select or poll).

Instead of evolving the struct sigevent notification methods to allow you to continue using standard POSIX interfaces like lio_listio(), mq_notify() or timer_create() while queuing completion notifications to a kevent completion queue (much the way the Solaris port API is designed, or the the API proposed by Ulrich Drepper in "The Need for Asynchronous, Zero-Copy Network I/O" as found at
http://people.redhat.com/drepper/newni.pdf ), kevent choooses to follow the FreeBSD route and introduce an entirely new and incompatible method of requesting and reporting event notifications (while also managing to be incompatible with FreeBSD's kqueue).

This is done through the introduction of two new syscalls and a variety of supporting datatypes. The first function, kevent_ctl(), is used to create and manipulate kevent queues, while the second, kevent_get_events(), is use to wait for new events.

They operate as follows:

int kevent_ctl(int fd, unsigned int cmd, unsigned int num, void *arg);

fd is the file descriptor referring to the kevent queue to manipulate. It is ignored if the cmd parameter is KEVENT_CTL_INIT.

cmd is the requested operation. It can be one of the following:

KEVENT_CTL_INIT - create a new kevent queue and return it's file
descriptor. The fd, num, and arg parameters are ignored.

KEVENT_CTL_ADD, KEVENT_CTL_MODIFY, KEVENT_CTL_REMOVE - add new,
modify existing, or remove existing event notification requests.

num is the number of struct ukevent in the array pointed to by arg

arg is an array of struct ukevent. Why it is of type void* and not
struct ukevent* is a mystery.

When called, kevent_ctl will carry out the operation specified in the cmd parameter.

int kevent_get_events(int ctl_fd, unsigned int min_nr,
unsigned int max_nr, unsigned int timeout, void *buf, unsigned flags)

ctl_fd is the file descriptor referring to the kevent queue.

min_nr is the minimum number of completed events that
kevent_get_events will block waiting for.

max_nr is the number of struct ukevent in buf.

timeout is the number of milliseconds to wait before returning less
than min_nr events. If this is -1, I *think* it'll wait indefinitely, but I'm not sure that msecs_to_jiffies(-1) ends up being MAX_SCHEDULE_TIMEOUT

buf is a pointer an array of struct ukevent. Why it is of type void*
and not struct ukevent* is a mystery.

flags is unused.

When called, kevent_get_events will wait timeout milliseconds for at least min_nr completed events, copying completed struct ukevents to buf and deleting any KEVENT_REQ_ONESHOT event requests.

The bulk of the interface is entirely done through the ukevent struct. It is used to add event requests, modify existing event requests, specify which event requests to remove, and return completed events.

struct ukevent contains the following members:

struct kevent_id id
This is described as containing the "socket number, file descriptor and so on", which I take to mean it contains an fd, however for some mysterious reason struct kevent_id contains __u32 raw[2] and (for KEVENT_POLL events) the actual fd is placed in raw[0] and raw[1] is never mentioned except to faithfully copy it around.

For KEVENT_TIMER events, raw[0] contains a relative time in milliseconds and raw[1] is still not used.

Why the struct member is called "raw" remains a mystery.

__u32 type
The actual event type, either KEVENT_POLL for fd polling or KEVENT_TIMER for timers.

__u32 event
For events of type KEVENT_POLL, event contains the polling flags of interest (i.e. POLLIN, POLLPRI, POLLOUT, POLLERR, POLLHUP, POLLNVAL).

For events of type KEVENT_TIMER, event is ignored.

__u32 req_flags
Per-event request flags. Currently, this may be 0 or KEVENT_REQ_ONESHOT to specify that the event be removed after it is fired.

__u32 ret_flags
Per-event return flags. This may be 0 or a combination of KEVENT_RET_DONE if the event has completed or KVENT_RET_BROKEN if "the event is broken", which I take to mean any sort of error condition. DONE|BROKEN is a valid state, but I don't really know what it means.

__u32 ret_data[2]
Event return data. This is unused by KEVENT_POLL events, while KEVENT_TIMER inexplicably places jiffies in ret_data[0]. If the event is broken, an error code is placed in ret_data[1].

union { __u32 user[2]; void *ptr; }
An anonymous union (which is a fairly recent C addition) containing data saved for the user and otherwise ignored by the kernel.

For KEVENT_CTL_ADD, all fields relevant to the event type must be filled (id, type, possibly event, req_flags). After kevent_ctl(..., KEVENT_CTL_ADD, ...) returns each struct's ret_flags should be checked to see if the event is already broken or done.

For KEVENT_CTL_MODIFY, the id, req_flags, and user and event fields must be set and an existing kevent request must have matching id and user fields. If a match is found, req_flags and event are replaced with the newly supplied values. If a match can't be found, the passed in ukevent's ret_flags has KEVENT_RET_BROKEN set. KEVENT_RET_DONE is always set.

For KEVENT_CTL_REMOVE, the id and user fields must be set and an existing kevent request must have matching id and user fields. If a match is found, the kevent request is removed. If a match can't be found, the passed in ukevent's ret_flags has KEVENT_RET_BROKEN set. KEVENT_RET_DONE is always set.

For kevent_get_events, the entire structure is returned with ret_data[0] modified to contain jiffies for KEVENT_TIMER events.

--

Having looked all this over to figure out what it actually does, I can make the following comments:

- there's a distinct lack of any sort of commenting beyond brief descriptions of what the occasional function is supposed to do

- the kevent interface is all the horror of the BSD kqueue interface, but with no compatibility with the BSD kqueue interface.

- lots of parameters from userspace go unsanitized, although I'm not sure if this will actually cause problems. At the very least, there should be checks for unknown flags and use of reserved fields, lest somebody start using them for their own purposes and then their app breaks when a newer version of the kernel starts using them itself.

- timeouts are specified as int instead of struct timespec.

- kevent_ctl() and kevent_get_events() take void* for no discernible reason.

- KEVENT_POLL is less functional than epoll (no return of which events were actually signalled) and KEVENT_TIMER isn't as flexible as POSIX interval timers (no clocks, only millisecond resolution, timers don't have separate start and interval values).

- kevent_get_events() looks a whole lot like io_getevents() and a kevent fd looks a whole lot like an io_context_t.

- struct ukevent has problems/inconsistencies -- id is wrapped in it's own member struct, while user and ret_data aren't; id's single member is named raw which does nothing to describe it's purpose; the user data is an anonymous union, which is C99 only and might not be widely supported, req_flags and ret_flags are more difficult to visually distinguish than they have to be; and every member name could use a ukev_ prefix.

--

P.S.

Dear DaveM,

Go fuck yourself.

Love,
Nicholas

Signature · 1 line

Nicholas Miell <[email protected]>

Quoted 9 lines · Nicholas Miell

int kevent_get_events(int ctl_fd, unsigned int min_nr,
unsigned int max_nr, unsigned int timeout, void *buf, unsigned flags)

ctl_fd is the file descriptor referring to the kevent queue.

min_nr is the minimum number of completed events that
kevent_get_events will block waiting for.

Quoted 6 lines

max_nr is the number of struct ukevent in buf.

timeout is the number of milliseconds to wait before returning less
than min_nr events. If this is -1, I *think* it'll wait indefinitely, but I'm not sure that msecs_to_jiffies(-1) ends up being MAX_SCHEDULE_TIMEOUT

You forget the case for non-blocked file descriptor. Here is comment from the code:

* In nonblocking mode it returns as many events as possible, but not more than @max_nr.
* In blocking mode it waits until timeout or if at least @min_nr events are ready.

Quoted 24 lines

buf is a pointer an array of struct ukevent. Why it is of type void*
and not struct ukevent* is a mystery.

flags is unused.

When called, kevent_get_events will wait timeout milliseconds for at least min_nr completed events, copying completed struct ukevents to buf and deleting any KEVENT_REQ_ONESHOT event requests.

The bulk of the interface is entirely done through the ukevent struct. It is used to add event requests, modify existing event requests, specify which event requests to remove, and return completed events.

struct ukevent contains the following members:

struct kevent_id id
This is described as containing the "socket number, file descriptor and so on", which I take to mean it contains an fd, however for some mysterious reason struct kevent_id contains __u32 raw[2] and (for KEVENT_POLL events) the actual fd is placed in raw[0] and raw[1] is never mentioned except to faithfully copy it around.

Quoted 4 lines

For KEVENT_TIMER events, raw[0] contains a relative time in milliseconds and raw[1] is still not used.

Why the struct member is called "raw" remains a mystery.

If you followed previous patchsets you could find, that there were network AIO, fs IO and fs-inotify-like notifications.
Some of them use that fields.
I got two u32 numbers to be "union"ed with pointer like user data is. That pointer should be obtained through Ulrich's dma_alloc() and friends.

Quoted 16 lines

__u32 type
The actual event type, either KEVENT_POLL for fd polling or KEVENT_TIMER for timers.

__u32 event
For events of type KEVENT_POLL, event contains the polling flags of interest (i.e. POLLIN, POLLPRI, POLLOUT, POLLERR, POLLHUP, POLLNVAL).

For events of type KEVENT_TIMER, event is ignored.

__u32 req_flags
Per-event request flags. Currently, this may be 0 or KEVENT_REQ_ONESHOT to specify that the event be removed after it is fired.

Quoted 6 lines

__u32 ret_flags
Per-event return flags. This may be 0 or a combination of KEVENT_RET_DONE if the event has completed or KVENT_RET_BROKEN if "the event is broken", which I take to mean any sort of error condition. DONE|BROKEN is a valid state, but I don't really know what it means.

DONE means that event processing is completed and it can be read back to userspace, if in addition it contains BROKEN it means that kevent is broken.

Quoted 4 lines

__u32 ret_data[2]
Event return data. This is unused by KEVENT_POLL events, while KEVENT_TIMER inexplicably places jiffies in ret_data[0]. If the event is broken, an error code is placed in ret_data[1].

Each kevent user can place here any hints it wants, for example network socket notifications place there length of the accept queue and so on.

In error condition error is placed there too.

Quoted 10 lines

union { __u32 user[2]; void *ptr; }
An anonymous union (which is a fairly recent C addition) containing data saved for the user and otherwise ignored by the kernel.

For KEVENT_CTL_ADD, all fields relevant to the event type must be filled (id, type, possibly event, req_flags). After kevent_ctl(..., KEVENT_CTL_ADD, ...) returns each struct's ret_flags should be checked to see if the event is already broken or done.

Quoted 6 lines

For KEVENT_CTL_MODIFY, the id, req_flags, and user and event fields must be set and an existing kevent request must have matching id and user fields. If a match is found, req_flags and event are replaced with the newly supplied values. If a match can't be found, the passed in ukevent's ret_flags has KEVENT_RET_BROKEN set. KEVENT_RET_DONE is always set.

DONE means that user's request is completed.
I.e. it was copied from userspace, watched, analyzed and somehow processed.

Quoted 8 lines

For KEVENT_CTL_REMOVE, the id and user fields must be set and an existing kevent request must have matching id and user fields. If a match is found, the kevent request is removed. If a match can't be found, the passed in ukevent's ret_flags has KEVENT_RET_BROKEN set. KEVENT_RET_DONE is always set.

For kevent_get_events, the entire structure is returned with ret_data[0] modified to contain jiffies for KEVENT_TIMER events.

ret_data can contain any hint kernel wants to put there. It can contain 0.

Quoted 12 lines

--

Having looked all this over to figure out what it actually does, I can make the following comments:

- there's a distinct lack of any sort of commenting beyond brief descriptions of what the occasional function is supposed to do

- the kevent interface is all the horror of the BSD kqueue interface, but with no compatibility with the BSD kqueue interface.

Quoted 5 lines

- lots of parameters from userspace go unsanitized, although I'm not sure if this will actually cause problems. At the very least, there should be checks for unknown flags and use of reserved fields, lest somebody start using them for their own purposes and then their app breaks when a newer version of the kernel starts using them itself.

All parameters which are not checked are not used.

If user puts own flags where it is not allowed it to do (like ret_flags) he creates problems for himself. No one complains when arbitrary number is placed into file dsecriptor and write() fails.

Quoted 1 line

- timeouts are specified as int instead of struct timespec.

timespec uses long, which is wrong.
I can put there any other structure which has strict types - no longs, that's the rule, no matter if there is a wrappers in per-arch syscall code.

poll alwasy ued millisecods and all are happy.

Quoted 2 lines

- kevent_ctl() and kevent_get_events() take void* for no discernible reason.

Because interfaces are changed - they used contorl block before, and now they do not. There is an opinion from Cristoph that syscall there is wrong too and better to use ioctls(), so I do not change it right now, since it can be changed in future (again).

Quoted 4 lines

- KEVENT_POLL is less functional than epoll (no return of which events were actually signalled) and KEVENT_TIMER isn't as flexible as POSIX interval timers (no clocks, only millisecond resolution, timers don't have separate start and interval values).

That's nonsence - kevent returns fired events,

POSIX timer API can only
use timers. When you can put network AIO into timer API call me, I will buy your a t-shrt.

Your meaning of "separate start and interval values" is not correct, please see how both timers work.

The only thing correct is that it only support millisecond resolution - I use poll quite for a while and it is really good interface, so it was copied from there.

Quoted 9 lines

- kevent_get_events() looks a whole lot like io_getevents() and a kevent fd looks a whole lot like an io_context_t.

- struct ukevent has problems/inconsistencies -- id is wrapped in it's own member struct, while user and ret_data aren't; id's single member is named raw which does nothing to describe it's purpose; the user data is an anonymous union, which is C99 only and might not be widely supported, req_flags and ret_flags are more difficult to visually distinguish than they have to be; and every member name could use a ukev_ prefix.

I described what id is and why it is placed into u32[2] - it must be union'ed with pointer, when such interface will be created. How can you describe id for inode notification and user pointer?

As you can see there are no problems with understanding how it works - I'm sure it has not took you too much time, I think writing previous messages took much longer.

Now my point:
1. unified interface - since there are many types of different event mechanisms (already implemented, but not theoretical handwaving), I created unified interface, which does not know about what the event is provided, it just routes it into appropriate storage and start processing. Anyone who thinks that kevents must have separate interface for each type of events just do not see, how many types there are. It is simple to wrap it into epoll and POSIX timers, but there are quite a few others - inotify, socket notifications, various AIO implementatinos. Who will create new API for them?

If you think that kevents are going to be used through wrapper library - implement there any interface you like. If you do not, consider how many syscalls are required, and finally the same function will be called.

2. Wrong documantation and examples.
For the last two weeks interface were changed at least three (!) times. Do you really think that I have some slaves in the cellar? When interface is ready I will write docs and change examples. But even with old applicatinos, it is _really_ trivial to understand what parameter is used and where, especially with excellent LWN articles.

And actually I do not see that this process comes to it's end -

NO FSCKING ONE knows what we want!

So I will say as author what _I_ want.

Until there is strong objection on API, nothing will be changed.

Something will be changed only when there are several people who acks the change.

This can end up with declining of merge - do not care, I hack not for the entry in MAINTAINERS, but because I like the process, and I can use it with external patches easily.

Nick, you want POSIX timers API? Ok, I can change it, if several core developers ack this. If they do not, I will not even discuss it. You can implement it as addon, no problem.

Dixi.

Quoted 6 lines

--

P.S.

Dear DaveM,

Quoted 4 lines

Go fuck yourself.

Love,
Nicholas

In a decent society you would have your nose broken... But in virtual one you just can not be considered as serious person.

Quoted 18 lines · Randy.Dunlap

Quoted 6 lines · On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:

Quoted 5 lines · Evgeniy Polyakov

Quoted 3 lines · Nicholas Miell

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 could maybe write it down somewhere?

Quoted 6 lines

Quoted 2 lines

I will write documantation, but as you can see some interfaces are changed.

Thanks; rapidly changing interfaces need good documentation even more than stable interfaces simply because reverse engineering the intended API from a changing implementation becomes even more difficult.

OK, I don't quite get it.
Can you be precise about what you would like?

Quoted 6 lines

a.  good documentation
b.  a POSIX API
c.  a Windows-compatible API
d.  other?

and we won't make you use any of this code.

I want something that I can be confident won't be replaced again in two years because nobody noticed problems with the old API design or they're just feeling very NIH with their snazzy new feature.

Maybe then we won't end up with another in the { signal/sigaction, waitpid/wait4, select/pselect, poll/ppol, msgrcv, mq_receive, io_getevents, aio_suspend/aio_return, epoll_wait, inotify read, kevent_get_events } collection -- or do you like having a maze of twisted interfaces, all subtly different and none supporting the complete feature set?

Good documentation giving enough detail to judge the design and an API that fits with the current POSIX API (at least, the parts that everybody agrees don't suck) goes a long way toward assuaging my fears that this won't just be another waste of effort, doomed to be replaced by the Next Great Thing (We Really Mean It This Time!) in unified event loop API design or whatever other interface somebody happens to be working on.

---

This is made extraordinarily difficult by the fact kernel people don't even agree themselves on what APIs should look like anyway and Linus won't take a stand on the issue -- people with influence are simultaneously arguing things like:

- ioctls are bad because they aren't typesafe and you should use syscalls instead because they are typesafe

- ioctls are good, because they're much easier to add than syscalls, type safety can be supplied by the library wrapper, and syscalls are a (relatively) scarce resource, harder to wire up in the first place, and are more difficult to make optional or remove entirely if you decide they were a stupid idea.

- multiplexors are bad because they're too complex or not typesafe

- multiplexors are good because they save syscall slots or ioctl numbers and the library wrapper provides the typesafety anyway.

- instead of syscalls or ioctls, you should create a whole new filesystem that has a bunch of magic files that you read from and write to in order to talk to the kernel

- filesystem interfaces are bad, because they're take more effort to write than a syscall or a ioctl and nobody seems to know how to maintain and evolve a filesystem-based ABI or make them easy to use outside of a fragile shell script (see: sysfs)

- that everything in those custom filesystems should ASCII strings and nobody needs an actual grammar describing how to parse them, we can just break userspace whenever we feel like it

- that everything in those custom filesystems should be C structs, and screw the shell scripts

- new filesystem metadata should be exposed by:
- xattrs
- ioctls
- new syscalls
or
- named streams/forks/not-xattrs
and three out of four of these suggestions are completely wrong for some critical reason

- meanwhile, the networking folks are doing everything via AF_NETLINK sockets instead of syscalls or ioctl or whatever, I guess because the network stack is what's most familiar to them

- and there's the usual arguments about typedefs verses bare struct names, #defines verses enums, returning 0 on success vs. 0 on failure, and lots of other piddly stupid stuff that somebody just needs to say "this is how it's done and no arguing" about.

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.

It'd probably make Evgeniy's life easier if you could just point at the interface guidelines and say "you did this wrong" instead of random people telling him to change his design and random other people telling him to change it back.

Quoted 8 lines · Nicholas Miell

OK, so with literally a dozen different interfaces to queue events to userspace, all of which are apparently inadequate and in need of replacement by kevent, don't you want to slow down a bit and make sure that the kevent API is correct before it becomes permanent and then just has to be replaced *again* ?

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 topic that will singe my fur, but what is wrong with the kqueue API? Will I really have to implement support for yet another event API in my program.

Rakshasa

Quoted 4 lines

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.

I do not understand, what do you mean?
It is obviously allowed to poll and change kevents at the same time.

Quoted 3 lines

Maybe this is a topic that will singe my fur, but what is wrong with the kqueue API? Will I really have to implement support for yet another event API in my program.

Why did I not implemented it like Solaris did?
Or FreeBSD did?
It was designed with features mention on AIO homepage in mind, but not to be compatible with some other implementation.
And why should it be?

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 (polling) is called.

It may also choose to update the filters immediately with the same call.

Quoted 9 lines

Quoted 3 lines

Maybe this is a topic that will singe my fur, but what is wrong with the kqueue API? Will I really have to implement support for yet another event API in my program.

Why did I not implemented it like Solaris did?
Or FreeBSD did?
It was designed with features mention on AIO homepage in mind, but not to be compatible with some other implementation.
And why should it be?

If it can be, why should it not be? At least, if you reinvent the wheel its advantages should be obvious.

Considering that kqueue is available on more popular OSes like darwin it would ease portability greatly if there was a shared event API. That is, unless you think there's something fundamentally wrong with their design.

Your interface:

+asmlinkage long sys_kevent_get_events(int ctl_fd, unsigned int min, unsigned int max,

(quoted diff) +2 -0

+               unsigned int timeout, void __user *buf, unsigned flags);
+asmlinkage long sys_kevent_ctl(int ctl_fd, unsigned int cmd, unsigned

int num, void __user *buf);

BSD's kqueue:

struct kevent {

 uintptr_t ident;        /* identifier for this event */
 short     filter;       /* filter for event */
 u_short   flags;        /* action flags for kqueue */
 u_int     fflags;       /* filter flag value */
 intptr_t  data;         /* filter data value */
 void      *udata;       /* opaque user data identifier */

};

From your description there is a serious problem with arches which

int kevent(int kq, const struct kevent *changelist, int nchanges, struct kevent *eventlist, int nevents, const struct timespec *timeout);

The only thing missing in BSD's kevent is the min/max parameters, the various filters in kevent_get_events either have equivalent filters or could be added as extensions. (I didn't look too carefully through them)

On the other hand, your API lacks the ability to pass changes when polling, as mentioned above. It would be preferable if the timeout parameter was either timespec or timeval.

Rakshasa

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 they are always added into kqueue in BSDs before started to be checked, so old events will be returned first)? And currently ready events can be read through mapped buffer without any syscall at all.
And Linux syscall is much cheaper than BSD's one.
Consider (especially apped buffer) that issues, it really does not cost interface complexity.

First of all, there are completely different types. Design of the in-kernel part is very different too.

Quoted 10 lines

BSD's kqueue:

struct kevent {

 uintptr_t ident;        /* identifier for this event */
 short     filter;       /* filter for event */
 u_short   flags;        /* action flags for kqueue */
 u_int     fflags;       /* filter flag value */
 intptr_t  data;         /* filter data value */
 void      *udata;       /* opaque user data identifier */

};

From your description there is a serious problem with arches which supports different width of the pointer. I do not have sources of ny BSD right now, but if it is really like you've described, it can not be used in Linux at all.

No way - timespec uses long.

Quoted 1 line

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 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.

Quoted 2 lines

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 nothing at all can be done, for datastructures exposed to userspace via mmap()'d buffers, which is what kevent will be doing.

This is what Alexey is trying to explain to you.

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 struct kevent, which is the only (interface related) thing that will be exposed.

Rakshasa

Quoted 5 lines · Jari Sundell

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 struct kevent, which is the only (interface related) thing that will be exposed.

void * in structure exported to userspace is forbidden. long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

Quoted 7 lines · On Wed, 23 Aug 2006 10:56:59 +0400 Evgeniy Polyakov <[email protected]> wrote:

Quoted 5 lines · Jari Sundell

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 struct kevent, which is the only (interface related) thing that will be exposed.

Quoted 5 lines

void * in structure exported to userspace is forbidden. long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

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 it to a __u64 nanosecond counter would be basically free on 64-bit machines, and not very expensive on 32-bit, no?

Let's then place there a structure with 64bit seconds and nanoseconds, similar to timspec, but without longs there.

Quoted 3 lines · Evgeniy Polyakov

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. Remember you might be still alive then ;-)

Ok one could argue that on 32bit architectures 2038 is so deeply embedded that it doesn't make much difference, but I still think it would be better to not readd it to new interfaces there.

64bit longs on 32bit is fine, as long as you use aligned_u64, never long long or u64 (which has varying alignment between i386 and x86-64)

-Andi

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 it to a __u64 nanosecond counter would be basically free on 64-bit machines, and not very expensive on 32-bit, no?

From: Andrew Morton <[email protected]>
Date: Wed, 23 Aug 2006 00:07:58 -0700

Quoted 4 lines

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.

Quoted 2 lines

Switching it to a __u64 nanosecond counter would be basically free on 64-bit machines, and not very expensive on 32-bit, no?

If it ends up in a structure we'll need to use the "aligned_u64" type in order to avoid problems with 32-bit x86 binaries running on 64-bit kernels.

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.

Quoted 7 lines · On Wed, 23 Aug 2006 10:56:59 +0400 Evgeniy Polyakov <[email protected]> wrote:

Quoted 5 lines · Jari Sundell

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 struct kevent, which is the only (interface related) thing that will be exposed.

Quoted 5 lines

void * in structure exported to userspace is forbidden. long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

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 it to a __u64 nanosecond counter would be basically free on 64-bit machines, and not very expensive on 32-bit, no?

Quoted 20 lines · Andrew Morton

Quoted 7 lines · On Wed, 23 Aug 2006 10:56:59 +0400 Evgeniy Polyakov <[email protected]> wrote:

Quoted 5 lines · Jari Sundell

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 struct kevent, which is the only (interface related) thing that will be exposed.

Quoted 5 lines

void * in structure exported to userspace is forbidden. long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

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.

Quoted 2 lines

Switching it to a __u64 nanosecond counter would be basically free on 64-bit machines, and not very expensive on 32-bit, no?

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 really not so good idea.

Quoted 5 lines

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 really not so good idea.

OK. One could do u32 seconds/u32 nsecs, but a simple aligned_u64 will be better for 64-bit machines, and OK for 32-bit.

void * in structure exported to userspace is forbidden.

long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

Quoted 1 line · Evgeniy Polyakov

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?

Quoted 4 lines

long in syscall requires wrapper in per-arch code (although that workaround _is_ there, it does not mean that broken interface should be used).
poll uses millisecods - it is perfectly ok.

The kernel is there to hide those ugly implementation details from the user, so I don't care that much about a workaround being required in some cases. More important, IMHO is consistency with the POSIX system calls.

I guess as long as you use usec, at least it won't be a pain to use.

Rakshasa

Quoted 5 lines · Jari Sundell

Quoted 1 line · Evgeniy Polyakov

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?

Yes, exactly about it.

I put union {
        u32 a[2];
        void *b;
}

epcially to eliminate that problem.

And I'm not that sure aboit stuff like uptr_t or how they call pointers in userspace and kernelspace.

ukevent is aligned to 8 bytes already (it's size selected to be 40 bytes), so it should not be a problem.

Quoted 1 line

Eric

Quoted 10 lines

Quoted 2 lines

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;
}

epcially to eliminate that problem.

It's just random data of a known maximum size appended to the struct, I'm sure you can find a clean way to handle it. If you mangle the first variable name in your union, you'll end up with something that should be usable instead of udata.

Quoted 2 lines

And I'm not that sure aboit stuff like uptr_t or how they call pointers in userspace and kernelspace.

Well, I can't find any use of pointers in your struct ukevent, nor in any of the kqueue events in my man page. So if this is a deficit it applies to both, I guess?

Quoted 4 lines

ukevent is aligned to 8 bytes already (it's size selected to be 40 bytes), so it should not be a problem.

Quoted 1 line

Eric

Even if it is so, wouldn't it be better to be explicit about it?

Rakshasa

No, it will change sizes of the structure in kernelspace and userspace, so they just can not communicate.

Quoted 3 lines · Evgeniy Polyakov

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   flags;        /* action flags for kqueue */
 u_int     fflags;       /* filter flag value */

union {
u32 _data_padding[2];
intptr_t data; /* filter data value */
};

union {
u32 _udata_padding[2];
void *udata; /* opaque user data identifier */
};
};

I'm not missing anything obvious here, I hope.

Rakshasa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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 convert your parameters into above structure.

Quoted 4 lines · Evgeniy Polyakov

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 convert your parameters into above structure.

7.18.1.4 Integertypes capable of holding object pointers

"1 The following type designates a signed integer type with the property that any valid
pointer to void can be converted to this type, then converted back to pointer to void,
and the result will compare equal to the original pointer:"

Dunno if this means that x86-64 needs yet another typedef, or if using long for intptr_t is incorrect. But assuming a different integer type was used instead of intptr_t, that is known to be able to hold a pointer, would there still be any problems?

I'm unable to see anything specific about AIO in your kevent patch that these modifications wouldn't support.

Rakshasa

Currently a user can create a user kevents in two ways:

a) simply open() the kevent chardevice
b) use sys_kevent_ctl with the KEVENT_CTL_INIT cmd type

both are equally easy to use for the user, but to support type b) a lot of code in kernelspace is required. remove type b to save lots of code without functionality loss.

I personally do not have objections against it, but it introduces additional complexies - one needs to open /dev/kevent and then perform syscalls on top of returuned file descriptor.

Quoted 3 lines · Evgeniy Polyakov

I personally do not have objections against it, but it introduces additional complexies - one needs to open /dev/kevent and then perform syscalls on top of returuned file descriptor.

it disalllows

int fd = sys_kevent_ctl(<random>, KEVENT_CTL_INIT, <random>, <random>);

in favour of only

int fd = open("/dev/kevent", O_SOMETHING);

which doesn't seem like a problem, especially as I really badly hope no one will use the syscalls but some library instead.

In addition to that I'm researching whether there's a better way to implement the other functionality instead of the two syscalls. But I'd rather let code speak, so wait for some patches from me on that.

Currently struct kevent_user.print is an array of unsigned long, but it's used as an array of pointers to struct kevent_mring everyewhere in the code.

Switch it to use the real type and cast the return value from __get_free_page / argument to free_page.

 include/linux/kevent.h      |    2 +-
 kernel/kevent/kevent_user.c |   31 +++++++++++--------------------
  2 files changed, 12 insertions(+), 21 deletions(-)

Signed-off-by Christoph Hellwig <[email protected]>