GeezerVison

I think the test class should be ran with Linux 2.27+ (to at least cover test_eventfd_initval) and then test_eventfd_semaphore (or any future tests that require use of the os.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 have some 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 with os.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 in test_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 for eventfd(). :-)

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 on https://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 above memfd_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 explains why 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 this man page, the initialization value is an unsigned 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 to UINT32_MAX while the maximum counter is UINT64_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 as eventfd, semaphore came a bit later.

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