[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [BUG] EPOLL_CLOEXEC undeclared

On 01/17/2012 04:42 AM, Philipp Hahn wrote:
>> glibc has supported epoll_create1() and EPOLL_CLOEXEC since glibc 2.9.
> That's the problem on this (old) Debian Lenny system:
> # dpkg-query -W libc6-dev
> libc6-dev       2.7-18.32.201101241735

And what kernel is that system running?  We already refuse to compile
lxc for RHEL 5 (kernel 2.6.18), as that particular kernel is too old to
usefully support namespace and other operations required by lxc.

It's one thing if the kernel call exists, but glibc is too old to expose
it, and another thing altogether if the kernel is too old to support it.

> For me this looks like lxc now only works with glibc >= 2.9, so an appropriate 
> check in configure should be added?

Yes, this sounds best to me.  Daniel, what is the minimum version of
kernel that you are willing to support for LXC, and given that, what is
the best thing to probe for in configure.ac to determine whether it even
makes sense to compile LXC?  We already reject kernels that lack
unshare() (dates back to 2.6.16) and LO_FLAGS_AUTOCLEAR (dates back to
Oct 2007, but I'm not sure which kernel introduced it).

> Or a fall-back to epoll_create()?

I'd prefer to reject old kernels, rather than add a fallback, if we
suspect anything else in our LXC implementation to not work with a
kernel that old.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]