On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> Regarding mukevent I'm thinking of a event-type specific struct, that is
> filled by the originating code, and placed into a per-event-type ring
> buffer (which requires modification of kevent_wait).
I'd personally worry about an implementation that used a per-event-type ring
buffer, because you're still left having to hack around starvation issues in
user-space. It is of course possible under the current model for anyone who
wants per-event-type ring buffers to have them - just make separate kevent
sets.
I haven't thought this through all the way yet, but why not have variable
length event structures and have the kernel fill in a "next" pointer in each
one? This could even be used to keep backwards binary compatibility while
adding additional fields to the structures over time, though no space would
be wasted on modern programs. You still end up with a question of what to do
in case of overflow, but I'm thinking the thing to do in that case might be
to start pushing overflow events onto a linked list which can be written back
into the ring buffer when space becomes available. The appropriate behavior
would be to throw new events on the linked list if the linked list had any
events, so that things are delivered in order, but write to the mapped buffer
directly otherwise.
Deciding when to do that is tricky, and I haven't thought through the
implications fully when I say this, but what about activating a bottom half
when more space becomes available, and let that drain overflowed events back
into the mapped buffer? Or perhaps the time to do it would be in the next
blocking wait, when the queue emptied?
I think it is very important to avoid any limits that can not be adjusted on
the fly at run-time by CAP_SYS_ADMIN or what have you. Doing it this way may
have other problems I've ignored but at least the big one - compile-time
capacity limits in the year 2006 - would be largely avoided :P
Nothing real solid yet, just some electrical storms in the grey matter...
Thanks,
Chase
-
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]
