Until now I haven’t been into system programming, so if the question seems to be inaccurate / naive / stupid, please help formulate it correctly.

While interested in two "mechanism": kqueue and epoll (and partly IOCP )

Question

How to programmatically find out that the necessary mechanism on the executable system is implemented and operational?

Details

The listed “mechanisms” (with the exception of IOCP , I probably don’t know) were not initially implemented. And they were added to the functionality from some kernel versions. As written on the net, for example, kqueue on FreeBSD - starting with version 4.1, epoll on Linux - starting from 2.5.44 kernel version. While I see for myself the only option - yes, watch the versions. But, something suggests that this is not correct, or rather, is not quite correct.

How more correct?

  • I think it is worth looking in the direction of autoconf - Mike
  • @Mike, of course you need to look. But this is build-time, and the issue of run-time. - Majestio
  • And how are you going to launch an application compiled, for example, to use epoll on glibc in which this function is not physically present. The loader is very offended and will not allow the application to start. If you build an application with a static - then it will start, but will cause a non-existent syscall, you need to see what the kernel does with the processes causing the wrong calls ... - Mike
  • I don’t know at all yet - the same Qt developers allow themselves to make binary installers. But they indicate distribution and core. And if I run "not there"? And also ... what can the bootloader be offended if the application is linked in statics? - Majestio
  • Well, there are two formal approaches: a stability test (fuzzer) and a compatibility test. The second is called, for example, TET, it costs about $ 100k without the right to use the results in the open source. About the first for BSD did not even hear. For Linux, there are free and open first and even some second ones (well, the same TET). opengroup.org/testing/testsuites - 0andriy

1 answer 1

I will talk about Linux, because I don’t know anything about FreeBSD. Let's start off with. that epoll (as well as poll ) is a system call. Those. This is a kernel call via ioctl.

This feature is supported by the kernel (this particular kernel), or not, you can find out by viewing the configuration file for generating this kernel using make menuconfig . There you can read:

  CONFIG_EPOLL: Disabling this option will cause the kernel to be built without support for epoll family of system calls.

In man we read:

epoll_create () has been added to version 2.6. Library support is provided in glibc starting with version 2.3.2.

The kernel, versions younger than 2.6 you hardly find now. Those. epoll support should be expected in all kernels if this particular kernel was not generated specifically WITHOUT this option.

I see only one way to check this in the program:

  • Call the epoll_create () function
  • If it returned -1, an error occurred.
  • If the errno variable contains the value EPERM, the operation is invalid.

Most likely, it will mean that it is impossible to use epoll. Mb alternatively inotify?

  • Plus a good answer. By the way ... how will Linux behave (should it lead) when calling the "wrong / unrealized" siscol? And how to handle this in Feng Shui? - Majestio
  • Are you talking about calling the syscall () function? This is quite rare in Linux, because : "Employing syscall () is a system call in the C library." There are few such cases, basically all library wrappers use the ioctl () call. In any case, a sign of calling an unimplemented kernel function is errno == EPERM. - Sergey