gentoo roadmap

[Brad Fitzpatrick]

> That sounds like the best way to go -- a Perl wrapper to launch and
> terminate multiple instances of the memcache daemon. (Even with each
> instance having separate configurations... handy!)
>
> A Perl wrapper would still be called with start-stop-daemon, but would
> allow for a lot more control and flexibility.

I'll work on that, then.

> I'll respond to your other email here, too, so as to not keep two
> threads going.
>
> To the best of my knowledge the epoll kernel patch is not included with
> any Gentoo kernels (Not gentoo-sources, for certain).  I've submitted a
> request to one of our Kernel guys (Bug #25671 @ bugs.gentoo.org) but I
> don't know when this will be handled.

/dev/epoll is the 'old' way.  The new way that Linus approved (which went
in 2.5) is the system call.  I'm not sure if libevent supports /dev/epoll.
On their website they say support for /dev/poll is planned, which is the
Solaris equivalent of /dev/epoll?

> So libevent is built as it would normally be when /dev/epoll was not
> present.  I'd assume that since epoll isn't included with the kernel
> that glibc isn't made "aware" of it (headers).  After things settle down
> from LWE I'll ask around a bit.

In any case, the headers should be updated in Gentoo for the new system
call numbers, so programs like libevent can build with all their
functionality, even if the current running kernel doesn't support it.

BTW, to test if memcached (rather, libevent) is using epoll:

# EVENT_SHOW_METHOD=1 memcached