timerfd is incompatible with common linux kernels

[brson]

We use timerfd for timers on linux, but this feature was only introduced in 2.6.22, and we expect these kernels to hang around in enterprise and embedded systems for years.

One solution is to feature-detect at build time, and turn timerfd off for snaps and bins.

[alexcrichton]

Another possibility is to completely axe the timerfd implementation of timers for libnative. We already have an implementation built on select which freebsd/osx are using, and linux could definitely use that. The only real reason for using timerfd is to get in theory more accurate periodic timers, but this is just an implementation detail rather than a public API-facing issue, so we can always change the implementation later if we so desire.

If we really do want to be gung-ho about supporting 2.6.18 and such, we need a bot building it to make sure this doesn't happen again.

For now, I would probably be more in favor of removing timerfd completely and opening an issue about adding a 2.6.18 bot. Perhaps in the future we'll have a better way to support a timerfd implementation.

[DaGenix]

It seems like its going to be a very small group of folks so conservative
that they are using a kernel from mid 2007 but also adventurous enough to
use a language that won't hit 1.0 until closer to 2015.
On Apr 10, 2014 8:01 PM, "Alex Crichton" notifications@github.com wrote:

Another possibility is to completely axe the timerfd implementation of
timers for libnative. We already have an implementation built on selectwhich freebsd/osx are using, and linux could definitely use that. The only
real reason for using timerfd is to get in theory more accurate periodic
timers, but this is just an implementation detail rather than a public
API-facing issue, so we can always change the implementation later if we so
desire.

If we really do want to be gung-ho about supporting 2.6.18 and such, we
need a bot building it to make sure this doesn't happen again.

For now, I would probably be more in favor of removing timerfd completely
and opening an issue about adding a 2.6.18 bot. Perhaps in the future we'll
have a better way to support a timerfd implementation.

Reply to this email directly or view it on GitHubhttps://github.com//issues/13447#issuecomment-40158403
.

[carllerche]

Feature detection at build time wouldn't be ideal for us. We build our rust code and ship shared objects. If the feature detection was at build time, we would need to ship builds for both kernels and figure out which so to load at runtime.

@DaGenix this is an incorrect assertion. Rust can be used to build shared objects that are distributed in binary form to customers. Also, while 2.6.18 is an "old kernel" red hat enterprise linux has shipped a version of their OS w/ kernel 2.6.18 as recently as October 2013. Also, there is still at least one fairly large cloud hosting provider providing VMs w/ linux kernel 2.6.18.

[DaGenix]

I don't doubt that 2.6.18 (and earlier) kernel will continue to be used for a long time. I would imagine that the majority of those folks have systems that are running fine and aren't interested in messing around with them. For that reason, I'm sceptical that that group of people is going to be interested in using any new software, let alone software written in a language that is still rapidly evolving.

Regardless, the point isn't all that important. It will be interesting to see if Rust based programs do make inroads with the RHEL5 crowd.