Evgeniy Polyakov wrote:
+ int kevent_commit(int ctl_fd, unsigned int start,
+ unsigned int num, unsigned int over);
I think we can simplify this interface:
int kevent_commit(int ctl_fd, unsigned int new_tail,
unsigned int over);
The kernel sets the ring_uidx value to the 'new_tail' value if the tail
pointer would be incremented (module wrap around) and is not higher then
the current front pointer. The test will be a bit complicated but not
more so than what the current code has to do to check for mistakes.
This approach has the advantage that the commit calls don't have to be
synchronized. If one thread sets the tail pointer to, say, 10 and
another to 12, then it does not matter whether the first thread is
delayed. If it will eventually be executed the result is simply a no-op
and since second thread's action supersedes it.
Maybe the current form is even impossible to use with explicit locking
at userlevel. What if one thread, which is about to call kevent_commit,
if indefinitely delayed. Then this commit request's value is never
taken into account and the tail pointer is always short of what it
should be.
There is one more thing to consider. Oftentimes the commit request will
be immediately followed by a kevent_wait call. It would be good to
merge this pair of calls. The two parameters new_tail and over could
also be passed to the kevent_wait call and the commit can happen before
the thread looks for new events and eventually goes to sleep. If this
can be implemented then the kevent_commit syscall by itself might not be
needed at all. Instead you'd call kevent_wait() and make the maximum
number of events which can be returned zero.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
