I think the test class should be ran with Linux 2.27+ (to at least covertest_eventfd_initval) and thentest_eventfd_semaphore (or any future tests that require use of theos.EFD_NONBLOCK flag) can require 2.30+. I'm not sure that it's entirely necessary or the number of devices it would actually be applicable to, but it seems like a better practice to havesome amount of test coverage for 2.27 - 2.29 since the feature will be included in those versions.

Also, would it be worthwhile to add a test that makes use of select (maybe for poll and epoll as well, via mixin), which uses them to check if the file descriptor is ready for reading or writing? I suspect those will be typically used withos.eventfd(), so ensuring that behavior works as expected would make sense to me. I'm just not certain if it makes sense to include those intest_os, or if there might be a better location.

It's actually 2.6.30, not 2.30. I'll fix that with the next commit. Linux Kernel 2.6.30 was released in 2009. It's highly unlikely that somebody is running a Kernel version between 2.6.27 and 2.6.30.

It's actually 2.6.30, not 2.30. I'll fix that with the next commit.

Ah, good catch. I completely didn't notice the missing.6, despite recently reading over the man page foreventfd(). :-)

It's highly unlikely that somebody is running a Kernel version between 2.6.27 and 2.6.30.

Yeah, after looking over the dates for the releases, I'm now in agreement that it would be highly unlikely. If anything, I suspect most on the 2.6.x branch would be using 2.6.39 or 2.6.32.

(Based onhttps://upload.wikimedia.org/wikipedia/en/timeline/40658da696ee210d2be5f221ac12e43b.png.)

I think this could be expanded upon a bit, specifically by:

1. Explicitly mentioning that the file descriptor is returned. I think it helps to make usage a bit more clear, and is done for the abovememfd_create().
2. Briefly summarize the use for it as a lightweight notifier/waiter for events. Compared to a pipe, it is more resource efficient as an event notifier.

E.g.

While I agree with making the low-level OS functions that are thin wrappers to existing OS APIs fairly minimal in terms of documentation details (especially if they're already well documented), I think the existing one could provide a bit more information to the user that explainswhy they might want to use it.

For the full details one can view the man page, but IMO, we at least should summarize the general purpose. Otherwise, I suspect it will significantly deter discoverability of the feature.

According to thisman page, the initialization value is anunsigned int. In any case, I don't think it's useful to document the maximum value.

I have updated the documentation. I think it's useful to document that the initial value is limited toUINT32_MAX while the maximum counter isUINT64_MAX - 1.

What's the rationale for adding an availability markup for this data member but not the others?

All other items have same availability aseventfd, semaphore came a bit later.

It seems all other modules / tests don't guard againstselect not being available. It looks like all platforms should support it (at leastselect.select).